Příspěvky

1

Sítě / Re:Výpadky IPv6 u Nordic Telecom

« kdy: 23. 01. 2026, 18:05:01 »

Ahoj, konečně mám zase čas se tomu věnovat.

Kód: [Vybrat]

mtr -b -w --tcp --port 443 mtu1280.frankfurt.test-ipv6.com
Start: 2026-01-23T16:17:31+0100
HOST: cachyos-desktop                                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a02:258f:0:bb5:da44:89ff:fe61:ff4a                                             0.0%    10    0.5   1.9   0.5  12.6   3.8
  2.|-- ???                                                                            100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 2001:41d8:1:442d::1                                                            10.0%    10  4125. 2428.  33.3 7189. 2167.3
        2001:41d8:1:443d::1
  4.|-- dynamic-2a00-1028-0001-00cc-0000-0000-0000-0002.ipv6.o2.cz (2a00:1028:1:cc::2) 50.0%    10   28.2  27.9  25.4  29.7   1.6
  5.|-- 2a07:cc80::a                                                                   40.0%    10   32.0  36.0  22.4  50.5   9.2
  6.|-- ???                                                                            100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 2001:978:2:81::3:4                                                             60.0%    10  7238. 3628.  29.1 7238. 3195.6
  8.|-- be8281.ccr21.bts01.atlas.cogentco.com (2001:550:0:1000::9a36:4959)             60.0%    10  5163. 1569.  27.6 5163. 2444.2
        be8282.ccr22.bts01.atlas.cogentco.com (2001:550:0:1000::9a36:495d)
  9.|-- be9463.ccr81.vie01.atlas.cogentco.com (2001:550:0:1000::9a36:48aa)             40.0%    10   33.3  37.9  28.1  56.8  11.4
        be9457.ccr82.vie01.atlas.cogentco.com (2001:550:0:1000::9a36:3f91)
 10.|-- be9456.ccr22.muc03.atlas.cogentco.com (2001:550:0:1000::9a36:3f8e)             90.0%    10  7225. 7225. 7225. 7225.   0.0
 11.|-- be7944.ccr42.fra05.atlas.cogentco.com (2001:550:0:1000::9a36:4b62)             80.0%    10  1119. 599.6  80.1 1119. 734.8
 12.|-- be5485.rcr31.fra06.atlas.cogentco.com (2001:550:0:1000::9a36:4d36)             70.0%    10  3168. 2452.  63.9 4125. 2123.1
        be8232.rcr31.fra06.atlas.cogentco.com (2001:550:0:1000::9a36:2671)
 13.|-- 2001:978:2:42::65                                                              40.0%    10   46.8  45.5  39.7  53.5   4.7
 14.|-- ae9.r22.fra02.mag.netarch.akamai.com (2600:1488:600a:2::14)                    60.0%    10   35.6  52.7  35.6  78.2  20.0
        ae10.r22.fra03.mag.netarch.akamai.com (2600:1488:600a:2::30)
        ae10.r21.fra03.mag.netarch.akamai.com (2600:1488:600a:2::28)
        ae9.r21.fra02.mag.netarch.akamai.com (2600:1488:600a:2::6)
 15.|-- ae0.r24.fra03.ien.netarch.akamai.com (2600:1488:600a:2::d)                     40.0%    10   58.7  49.5  38.5  58.7   7.9
        ae0.r22.fra02.ien.netarch.akamai.com (2600:1488:6009:2::1b)
        ae2.r24.fra03.ien.netarch.akamai.com (2600:1488:600a:2::2f)
 16.|-- 2600:3c0f:10:32::2                                                             60.0%    10   44.5  50.7  44.5  60.3   6.8
        2600:3c0f:10:32::1
 17.|-- 2600:3c0f:10:35::28                                                            40.0%    10   36.5  44.5  36.1  52.8   7.6
        2600:3c0f:10:35::27
 18.|-- 2600:3c0f:10::700                                                              60.0%    10   38.4  44.6  38.4  51.5   6.4
 19.|-- 2a01:7e01:e001:8a6::1280                                                       40.0%    10   45.9  41.9  34.1  47.5   5.6


Co je jeste zajimave: v tom pcapu je videt, ze odejde TCP SYN, ale uz se nevrati zadny SYN/ACK. Jako kdyby ty pakety nekdo po ceste zahodil. To by vubec nemelo souviset se zahazovanim ICMPv6, spis by to naznacovalo nejaky jiny problem.

tady by mohl být problém v tom, že nevím jak to zafiltrovat aby tam případně byly vidět i ICMPv6 ale jen ty související, ICMPv6 v lokální síti chodí hodně.

Dokazes si po ty 6tce pingnout nejaky interni stroj? Myslim tim zvenku.

Když v routeru vypnu IPv6 SPI Firewall tak se traceroute z dnscheck.org dostane až na mou IPv6, ale občas mě router odpoví a občas ne. Nechávám to teď zaplé, protože nevím co všechno se mi pak může dostat do sítě.

Když je ten firewall vypnutý tak stejně

Kód: [Vybrat]

curl https://mtu1280.frankfurt.test-ipv6.com/ip/?callback=?&size=1600 chodí náhodně.

2

Sítě / Výpadky IPv6 u Nordic Telecom

« kdy: 18. 01. 2026, 09:35:27 »

Ahoj

mám problémy s IPv6. Poprvé jsem na to narazil na přelomu roku, projevovalo se to tak, že občas git přes ssh na gitlab.com trval dlouho. Teď jsem se dostal k tomu to řešit. Ve wiresharku je vidět, že se snaží pripojit přes IPv6 ale nedostane žádnou odpověď, tak po 180s přepne na IPv4 a projde to bez problémů. Ale není to pravidlo, občas IPv6 spojení funguje bez problémů. V příloze je záznam err-gitlab.pcap, kde je vidět problém, a ok-gitlab.pcap kde je vidět, že vše proběhne v pořádku.
Když ke gitlab.com přistupuju z prohlížeče, tak je vidět, že prohlížeč se pokudí vanázat obě spojení současně a použije to, které se chytí dřív (gitlab-http.pcap).
Dál jsem vypozoroval, že na stránce test-ipv6.com mě náhodně různé testy ohledně IPv6 selžou (viz obrázky, ale i jiné).
Mám podeření na blokované ICMPv6 packet too big, ale medokážu to nijak potvrdit.
Zkouším teď curl https://mtu1280.frankfurt.test-ipv6.com/ip/?callback=?&size=1600 s různými velikostmi a není tam jasná hranice, občas mi projde 1600, občas neprojde ani 1000.

Jak jsem naznačil v nadpise máme internet od Nordic Telekom, máme doma NX510v s logem O2. Prístup do toho mám ale nevím co kde kontrolovat nebo změnit.

Rád bych tento problém vyřešil, ideálně jinak než deaktivací IPv6. Uvažuju, že se providerovi ozvu, ale chtěl bych mít nějaký konkrétní důkaz nebo podklad.

3

Server / Re:Chyby na různých discích na Btrfs poli

« kdy: 14. 10. 2024, 16:23:18 »

Tak napájení opraveno, pouštím scrub.

Jeste pohlidat teplotu, pokud ty disky jsou nad sebou namackane

Do disků foukají ventilátory, a podle logů teploty nepřesáhly 40˚C.

4

Server / Re:Chyby na různých discích na Btrfs poli

« kdy: 14. 10. 2024, 15:45:43 »

S.M.A.R.T. diagnostika disku: Klíčové položky, na které je potřeba se zaměřit:
    Reallocated_Sector_Ct: Počet přemapovaných sektorů. Zvýšený počet znamená problémy s povrchem disku.
    Pending_Sector: Počet sektorů čekajících na přemapování. Tento ukazatel je kritický.
    Uncorrectable_Sector: Počet neopravených sektorů.

kromě 1 realokovaného sektoru na jednom disku jsem tam neviděl problém, viz některý z předchozích příspěvků. (To že tam ten problém nevidím já neznamená že tam není)

Kontrola kabelů a připojení: Zkontrolovat fyzické připojení disku, zejména SATA/IDE kabely a napájecí kabely, které mohou být zdrojem problémů se čtením a zápisem dat.

Všechny sata kabely jsem před posledním scrubem vypojil a ty u kterých jsem měl pochybnosti vyměnil. Ale i tak tam byly chyby a to nejenom ty neopravitelné co tam jsou od minula.

Testování napájení: Nestabilní napájení může způsobovat problémy s diskem. V případě podezření na problémy s napájením je dobré zkontrolovat napájecí zdroje nebo zvážit použití UPS. Taky to, že všechny disky budou pověšené na jedné kšandě, stabilitě napájení moc nepřidá.

Mám to v této skříni: https://www.silverstonetek.com/en/product/info/server-nas/CS380/ . Má šuplíky na disky a k nim backplane. Zde mám máslo na hlavě, protože te%d jsem si to překontroloval, a našel jsem tam další napajecí konektory, které jsem neviděl.

Kontrola RAM: Vadná paměť RAM se může v důsledku projevit chybami na disku.

Memtest jedu od večera. Je tam 22 průchodů bez chyb. Asi to teď ale přeruším a přidám tam to chybějící napájení.

Test povrchu disku: Např. badblocks.

Ty dva nové 4TB seagate disky jsem první přejel badblocks - bez chyb. Pak jsem na ně nahrál data z těch 4TB WD, které jsem pak přejel badblocks - také bez chyb. Ty 3TB WD jsem netestoval, ale ty mě nebyly podezřelé.

Dál bych popřemýšlel nad tím, jestli je k filesystému s raid1 vhodné připojit dva potenciálně vadné disky a poté provést full rebalanc. Protože po tom rebalancu se alespoň některým datům může stát, že budou uložena právě a jen na těch dvou podezřelých discích. Pokud jsou ty disky podezřelé, otestoval bych je (smart, badblocks) někde jinde. Pokud tedy není k dispozici jiný systém, alespoň bych je v tom jediném možném systému otestoval samostatně předtím, než je připojím do raidu a nahraju na ně ostrá data.

Full rebalanc jsem udělal po tom, co mi vyšel scrub úplně bez chyb.


Půjdu teď přidat ty napájecí kabely, pak pustím scrub a uvidím co to udělá

5

Server / Re:Chyby na různých discích na Btrfs poli

« kdy: 13. 10. 2024, 08:30:20 »

Tak jsem tam kde jsem byl.
Po tom co mi scrub nenašel žádné chyby jsem odebral staré dísky a přidal ty 2 nové které jsem považoval za problémové. Mám tedy v poli 4x4TB a 2x3TB. Pak jsem udělal full rebalance abych ty data rovnoměrně rozložil, a pak jsem pro jistotu udělal další scrub.
Tento scrub nahlásil asi 1600 opravených chyb a 5 neopravitelných. Napadlo mě, jestli není problém v sata kabelech, tak jsem projistotu všechny u kterých nebylo patrné zda jsou na 6Gb/s vyměnil. Další scrub našel ty stejné neopravitelné chyby a 165 opravil.
Když jsem se díval do dmesg tak tam něco bylo ale nemyslím si, že to množství odpovídá počtu chyb na BTRFS.

poslední scrub:

Kód: [Vybrat]

UUID:             b9c58577-a996-4c69-bd43-4a2596eeb90d

Scrub device /dev/sde1 (id 4) history
Scrub started:    Sat Oct 12 13:02:00 2024
Status:           finished
Duration:         3:43:05
Total to scrub:   1.54TiB
Rate:             119.79MiB/s
Error summary:    csum=5
  Corrected:      5
  Uncorrectable:  0
  Unverified:     0

Scrub device /dev/sdb1 (id 5) history
Scrub started:    Sat Oct 12 13:02:00 2024
Status:           finished
Duration:         4:10:41
Total to scrub:   2.44TiB
Rate:             168.92MiB/s
Error summary:    no errors found

Scrub device /dev/sda1 (id 6) history
Scrub started:    Sat Oct 12 13:02:00 2024
Status:           finished
Duration:         4:21:21
Total to scrub:   2.44TiB
Rate:             162.00MiB/s
Error summary:    no errors found

Scrub device /dev/sdf1 (id 7) history
Scrub started:    Sat Oct 12 13:02:00 2024
Status:           finished
Duration:         3:38:16
Total to scrub:   1.54TiB
Rate:             122.43MiB/s
Error summary:    read=160 csum=5
  Corrected:      165
  Uncorrectable:  0
  Unverified:     0

Scrub device /dev/sdd1 (id 14) history
Scrub started:    Sat Oct 12 13:02:00 2024
Status:           finished
Duration:         5:24:37
Total to scrub:   2.45TiB
Rate:             131.26MiB/s
Error summary:    csum=5
  Corrected:      0
  Uncorrectable:  5
  Unverified:     0

Scrub device /dev/sdc1 (id 15) history
Scrub started:    Sat Oct 12 13:02:00 2024
Status:           finished
Duration:         5:24:30
Total to scrub:   2.45TiB
Rate:             131.31MiB/s
Error summary:    csum=5
  Corrected:      0
  Uncorrectable:  5
  Unverified:     0


6

Server / Re:Chyby na různých discích na Btrfs poli

« kdy: 11. 10. 2024, 07:01:21 »

Tak jsem smazal všechny IMGP1750.dng ze všech snapshotů,obnovil ze zálohy a už tam chyby nemám.

Děkuji všem za rady.

7

Server / Re:Chyby na různých discích na Btrfs poli

« kdy: 09. 10. 2024, 19:30:18 »

tak jsem zkusil obnovit marun/files/fotky/raw/2023-03-02/IMGP1750.dng ze zálohy, pustil sem scrub a uvidím.

8

Server / Re:Chyby na různých discích na Btrfs poli

« kdy: 08. 10. 2024, 17:26:25 »

RDa: díky za ochotu, ale z jižní moravy to je docela z ruky. Co se týče těch ostatních rad, to začíná být docela pokročilé a teď si úplně na takovéto experimenty netroufám. Počkám na další rady.

Jan Fikar: já bych očekával, že když scrub najde problém tak ho opraví z té druhé kopie. scrub už jsem pustil mnohokrát a pořád to tam visí.

rmrf: takový soubor tam aktuálně není, nemůže být v některém snapshotu? nešlo by zjistit ve kterém? btrfs check zkusím

Vantomas: dívám se teď že tam opravdu pár chyby komunikace s disky je. ale já sem ty disky i v pozicích prohazoval a pořád byly problémové ty stejné tak mě to mate.

Trident Vasco: smart sleduju na všech discích (přiložím). Smartem si nejsem úplně jistý, některým hodnotám nerozumím a u některých disků se stane že extended self test hodí chybu ale po zopakování chybu nehodí. Nas je z relativně nových desktopových komponent. MB je Gigabyte B560M D3H, CPU Intel(R) Pentium(R) Gold G6405 CPU @ 4.10GHz, a 2x KHX2133C14/8G, jediné 2 problémové místa vidím dodatečnou kartu SATA (MB neměla dost portů) a možná kabely, (celý lshw v příloze).

jirsik: chtěl bych to upřesnit. původně to jbod byl - neměl jsem dost kapacity. ale při první chybě jsem to nakonec rozšířil na raid1, ale mám pocit (úplně si to nepamatuju) že sem se poškozeného souboru tenkrát zbavil. Důvod proč jsem se snažil ty data přehrát byl, protože jsem chtěl ty disky otestovat, tudíž jsem se je snažil odstranit z pole, protože jsem o replace nevěděl tak sem šel cestou add a remove.

rmrf: jak jsem psal výše mám pocit že jsem se chyb zbavil, ale je to nějakou dobu a už si to nepamatuju. Pak jsem neměl čas to řešit

9

Server / Chyby na různých discích na Btrfs poli

« kdy: 07. 10. 2024, 18:49:45 »

Zdravím

postavil jsem si NAS a vytvořil na něm pole disků z btrfs.
Disky jsou tak trochu co dům dal. Nekteré starší, některé nové, ale hlídal jsem si aby neměly špatné sektory.
Původně jsem neměl na redundanci kapacitu tak jsem měl data:single a metadata:raid1.
Pravidelně jsem pouštěl scrub abych si ověřil že data nehnijí.
Jednou mě to ale opravdu našlo chybu na nějakém souboru. Naštěstí na něm nezáleželo tak jsem ho smazal a rozšířil jsem pole abych mohl mít data:raid1 a metadata:raid1c3.
Pak ale po jednom scrubu naskákalo 5 neopravitelných chyb na dvou discích (dva úplně nové stejné WD40EFPX-68C) a při dalším scrubu ty chyby nezmizely. Z logů nebylo patrné kde to nastalo, sice jsem hledal na internetu ale na nic jsem nepřišel.
Pak jsem bohužel na problém neměl čas a NAS stejně ležel většinu doby vyplý.
Teď jsem se k tomu opět dostal. Po dalším zkoumání mě nenapadlo nic lepšího než koupit 2 nové disky(tentokrát sem si řekl že koupím seagate ST4000NE001-2MA1), abych mohl z těchto disků data odlét a zkusit je na špatné sektory nebo s nimi něco udělat.
Tak jsem ty nové disky přidal do pole pomocí device add a problémové jsem dal odstraňovat pomocí device delete.
Jenže v průběhu odstraňování to napsalo prostě I/O error a nedokončilo se (u obou disků).
Na internetu jsem našel, že existuje btrfs replace a tím jsem vyměnil, ale během tohoto procesu vyskákalo do logu celá řada chyb, kterým nerozumím, a při následném scrubu vyskákaly také (přikládám log).

Není mě jasné proč chyby skáčou na těchto discích, zrovna nové ne staré. Není to ani šuplíkem v PC protože jsem v pátek kolem 4 hodiny PC vypl a jeden z problémových disků přestěhoval do jiné pozice.
A proč teď skáčou na těch nových. Očekával bych že se po srcubu nebo replacu ty chyby opraví.

Chtěl bych proto požádat o radu, kde dělám chybu a jak z toho ven. Už mě jen napadá koupit dostatek nových disků a data pomocí rsync překopírovat na nové pole a doufat že už to nenastane.

Kód: [Vybrat]

Model: ATA ST4000NE001-2MA1 (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  4001GB  4001GB  btrfs


Model: ATA WDC WD7500BPKX-8 (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  750GB  750GB  primary  btrfs


Model: ATA ST4000NE001-2MA1 (scsi)
Disk /dev/sdc: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  4001GB  4001GB  btrfs


Model: ATA WDC WD5000AAKS-0 (scsi)
Disk /dev/sdd: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  500GB  500GB  primary  btrfs


Error: /dev/sde: unrecognised disk label
Model: ATA WDC WD40EFPX-68C (scsi)                                       
Disk /dev/sde: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdf: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3001GB  3001GB  btrfs        data


Model: WD_BLACK SN770 250GB (nvme)
Disk /dev/nvme0n1: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  1128MB  1127MB  fat32                 boot, esp
 2      1128MB  239GB   238GB   btrfs
 3      239GB   250GB   10,7GB  linux-swap(v1)        swap


Model: Realtek RTL9210B-CG (scsi)
Disk /dev/sdk: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  512GB  512GB  primary  btrfs


Model: ATA WDC WD10EZEX-08M (scsi)
Disk /dev/sdi: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1000GB  1000GB  primary  btrfs


Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdg: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3001GB  3001GB  btrfs


Model: Patriot M.2 P300 128 (scsi)
Disk /dev/sdj: 128GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  128GB  128GB  primary  btrfs


Error: /dev/sdh: unrecognised disk label
Model: ATA WDC WD40EFPX-68C (scsi)                                       
Disk /dev/sdh: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:


disky sdb sdj a sdk úplně neřešte, přidal jsem je do pole ať mám větší manévrovací prostor, pak je odstraním.

Kód: [Vybrat]

Overall:
    Device size:   15.36TiB
    Device allocated:   12.79TiB
    Device unallocated:    2.57TiB
    Device missing:      0.00B
    Used:   12.77TiB
    Free (estimated):    1.29TiB (min: 886.65GiB)
    Free (statfs, df):    1.24TiB
    Data ratio:       2.00
    Metadata ratio:       3.00
    Global reserve: 512.00MiB (used: 0.00B)
    Multiple profiles:         no

Data,RAID1: Size:6.38TiB, Used:6.38TiB (99.87%)
   /dev/sdi1 614.00GiB
   /dev/sdf1    2.42TiB
   /dev/sda1    3.33TiB
   /dev/sdc1    3.33TiB
   /dev/sdg1    2.42TiB
   /dev/sdd1 151.00GiB
   /dev/sdb1 381.00GiB
   /dev/sdk1 162.00GiB

Metadata,RAID1C3: Size:8.00GiB, Used:7.41GiB (92.67%)
   /dev/sdi1    3.00GiB
   /dev/sdf1    4.00GiB
   /dev/sda1    5.00GiB
   /dev/sdc1    5.00GiB
   /dev/sdg1    3.00GiB
   /dev/sdb1    3.00GiB
   /dev/sdk1    1.00GiB

System,RAID1C3: Size:64.00MiB, Used:1.03MiB (1.61%)
   /dev/sda1   64.00MiB
   /dev/sdc1   32.00MiB
   /dev/sdd1   32.00MiB
   /dev/sdb1   32.00MiB
   /dev/sdk1   32.00MiB

Unallocated:
   /dev/sdi1 314.51GiB
   /dev/sdf1 314.52GiB
   /dev/sda1 314.96GiB
   /dev/sdc1 313.99GiB
   /dev/sdg1 314.52GiB
   /dev/sdd1 314.73GiB
   /dev/sdb1 314.60GiB
   /dev/sdj1 119.24GiB
   /dev/sdk1 313.91GiB


Kód: [Vybrat]

Linux server 6.8.0-45-generic #45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Sep 11 15:25:05 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy