Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

[Petr Kratochvíl]

Co to jsou přesně za disky?

Disky to jsou běžně dostupné mechanické všechny 8 TB, konkrétně tyto:

• 4x Seagate Archive Exos 5E8
• 1x Seagate IronWolf 8TB
• 2x Western Digital WD Red 8TB

Co to jsou přesně za disky? Fungovalo to dříve, nebo to je nové pole?

Pole je staré cca 6 měsíců (stejných 7 disků) a tyto problémy pozoruji cca 2 měsíce.

Dříve (před cca 5 měsíci) jsem na pole nakopíroval 8 TB z jiného disku, porovnal md5 checksum na původním disku a na poli a checksumy odpovídaly. A to jsem při zápisu a porovnávání normálně pole používal read-write na jiná data (zálohy serverů, ...).

Asi bych o víkendu zkusil downgrade na nějaký tak 6 měsíců starý kernel. Ale jestli problém bude stále, tak nevím. A jestli nebude, tak také nevím, zda pak zůstat na starém kernelu nebo jak najít příčinu (v changelogs a commitech kernelu?).

Může nás někam dovést ta souvislost problému s cache v disku?

Navíc mě trochu děsí, že pokud je příčina někde mezi disk-cache, řadič a kernelem, tak se totéž teoreticky může stát každému běžnému uživateli s jedním diskem. Akorát se o tom ani nedozví, pokud nepoužívá FS s checksumy dat (Btrfs, ZFS, ...).

[Reklama]

[dustin]

Jak moc je to pole plné? Výhodou ZFS je například synchronizace (resilvering) pouze obsazeného prostoru, narozdíl od mdadm. Tam resync 8TB disku na raid6 může být na hodně dlouho....

[Petr Kratochvíl]

Jak moc je to pole plné? Výhodou ZFS je například synchronizace (resilvering) pouze obsazeného prostoru, narozdíl od mdadm. Tam resync 8TB disku na raid6 může být na hodně dlouho....

Obsazeno cca 37 z 40 TB a do budoucna se počítá s podobným obsazením pole.

Navíc pro výběr Btrfs místo ZFS jsem měl po 2 letech vybírání a testování argumenty, které by ani elegantní resilvering nepřevážil.

[dustin]

No, btrfs s raid6 na 40TB, to přeji hodně štěstí :-)

[ByCzech]

Co to jsou přesně za disky?

Disky to jsou běžně dostupné mechanické všechny 8 TB, konkrétně tyto:

• 4x Seagate Archive Exos 5E8
• 1x Seagate IronWolf 8TB
• 2x Western Digital WD Red 8TB

No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".

[Reklama]

[mtd]

Jako první bych kouknul, jestli mají ty disky v pořádku napájení a jestli se nepřehřívají. Dokud není ok tohle, diagnostika ostatních věcí může vést k nesmyslným závěrům. A to stejné pro řadiče.

[Petr Kratochvíl]

No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".

Takže jsem špatně Googlil a omylem koupil zase šindele. To už se mi stalo kdysi se Seagate Archive a dodnes mám na něj špatné vzpomínky korenspondující s tímto krásným článkem o šindelovém zápisu (SMR):
https://diit.cz/clanek/recenze-8tb-seagate-archive

Moje zkušenosti se SMR tenkrát odpovídaly přesně názvu 3. kapitoly, tj. "Zahlcení disku do bezvědomí".

Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.

Na aktualizaci firmware se o víkendu podívám. Super by bylo, kdyby pomohla.

[ByCzech]

Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.

Teoreticky ano, jenže tyhle disky běžně lžou např. o tom, že data jsou komplet zapsána tam kde by měla být a jsou děsně překombinované samy o sobě a když se k tomu přidá NCQ, cache,... tak tohle se prostě při složitější konfiguraci (RAID) s nimi stává, že dělají co nemají a jedinou nadějí je nový firmware, který ty mezní stavy, které vznikají až v diskových polích ošetří, protože jednotlivé disky jsou obvykle OK, přestože se jak píšete dají lehce uštvat na random access. Navíc novější jednotky zdá se používají finty, kdy první zápisy jsou bez šindelů a až když se vyčerpá většina téhle klasické kapacity, začnou přerovnávat do šindelů a je zle, k tomu se přidá to, že firmware disku lže o kompletním zapsání dat ap. a problém je při souběhu specifického čtení/zápis na světě.

[Jan Forman]

SMR disky bych fakt vyndal, sám je používám, ale prostě jen osamocené nebo RAID1 jsou naprosto nevhodné do tohoto provozu.
Pokud se zápis nefragmentuje, zapíšou celkem rychle hodně dat, ale to v kombinaci se žurnálem není příliš častý jev.
Jsou vhodné asi jen na speciální použití a do datacenter popř. jako samostatný disk.

Ztrátu dat jsem ale nikdy neviděl. Nicméně pokud jsou tam čtyři a náhodně se odpojujou po překročení té neSMR oblasti, tak se můžou dít věci nečekané.

[Tester]

Skuste sa pohrat s nasledujucimi moznostami.

1. Vypnite HPET v BIOSe
2. Vyskusajte nasledujuce parametre kernelu.
libata.force=noncq
libata.force=1.5
libata.force=3.0

[Lol Phirae]

Ti asi mrdá, ne, narvat si do RAIDu SMRTky... 

[kkt1]

No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".

Takže jsem špatně Googlil a omylem koupil zase šindele. To už se mi stalo kdysi se Seagate Archive a dodnes mám na něj špatné vzpomínky korenspondující s tímto krásným článkem o šindelovém zápisu (SMR):
https://diit.cz/clanek/recenze-8tb-seagate-archive

Moje zkušenosti se SMR tenkrát odpovídaly přesně názvu 3. kapitoly, tj. "Zahlcení disku do bezvědomí".

Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.

Na aktualizaci firmware se o víkendu podívám. Super by bylo, kdyby pomohla.

https://www.seagate.com/www-content/datasheets/pdfs/exos-5e8DS1954-1-1709US-en_US.pdf
jsou smr, drive managed, tudiz jsi koupil blbe. Kombinace tech disku a raidu muze generovat nekonzistentni data.

[Lol Phirae]

Tak snad ještě praktickou poznámku...

Takže jsem špatně Googlil a omylem koupil zase šindele.

Vzhledem ke kvalitě dokumentace a ochotě výrobců přiznávat použití SMRtící technologie do jakékoliv objednávky disků automaticky do poznámky píšu (optimálně se zapnutým Caps Lockem): NESMÍ SE JEDNAT O SMR DISK!!!

V případě, že zjistím, že je to SMRtka, automaticky reklamuju s odkazem na objednávku. Vyřízeno, vyřešeno.

[RDa]

Kluci, ale zadny drive-managed SMR disk uz z principu nemuze produkovat nekonzistentni data, cache, ne-cache!
Kde mate dukaz ze tyhle disky nectou to, co jste do nich zapsali??

To, jak se tyto SMR interne chovaji odpovida modernim SSD se SLC cache (zapis jede do docasneho uloziste, po jehoz zaplneni rychlost znatelne poklesne - coz muze disk vyhodit z raid-pole u hw radice z duvodu ze nereaguje). Na pozadi se to pak vklada do bloku ktere lze prepisovat jen jednim smerem.

Ten 160 KiB blok je podle me spis jen v ramci jednoho stripe (podle presneho offsetu to muzes rict zda jo nebo ne). Delit poctem disku to nema tady smysl. Kdyby to nebyly dulezite data, tak bych rad videl co se to tam zmenilo a jak (klidne PM).

Pokud chces dal experimentovat, tak cti jak /dev/mdX tak /dev/sdX ze stejnych mist (resp. mel bys byt schopen spocitat kde se onen 160kB blok nachazi). V pripade, ze se zmeni data na 3 discich zaroven, tak to je regulerni zapis (coz spis neni, kdyz kontrola konzistence pole ti vraci errory). Takze to spis muze byt vadnej port/kabel na jednom disku (pokud ten offset bude pri dalsich chybach indikovat ze to je puvodem z jednoho disku). Nez experiment s jinou verzi kernelu bych zvazil experiment se znatelne jinym hw (intel^amd) a ponechat jen disky, vymenit i kabely.

[Lol Phirae]

a ponechat jen disky

Ano, ponechat disky, které jsou v RAIDu naprosto neprovozovatelné a vyhodit vše ostatní, to dává skutečně smysl.