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

[trubicoid2]

možná koukni na stabilitu napětí, zápis a čtení na 6 disků zároveň žere víc, než když testuješ jen po jednom disku postupně

zdroj to neudrží, napětí poklesne a máš blbosti

vyloučit to můžeš čtením z jednoho disku zatímco na všechny budeš třeba zapisovat, nebo dokonce zapisovat a číst, seek má asi největší spotřebu

[Reklama]

[RDa]

a ponechat jen disky

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

Pokud ma vadnej kabel, zdroj, pameti, cpu, tak mu sebelepsi disk nepomuze. Pokud sis nevsim, porad se hleda zavada. Vypnuti cache na disku jenom snizi pocet operaci a pravdepodobnost chyby klesne, ale neni to reseni ani duvod chyby. To by taky rovnou mohl zkusit jet na 1.5G - SATA gen I, nebo zkrouhnout traffic, aby se to "ustihalo". Taky to ale neni reseni!

[ByCzech]

Kluci, ale zadny drive-managed SMR disk uz z principu nemuze produkovat nekonzistentni data, cache, ne-cache!

Z principu ne, z praxe ano. já viděl už takové hromady vadných zařízení, že to ani nespočítám, takže tvrdit mi, že něco nemůže produkovat problémy je pro mě mimo realitu.

[j]

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

Jestli to nebude tim, ze ty netusis o cem pises, on nepouziva BRTFS RAID. Kdyby pouzival, nejspis by to fungovalo, protoze se to chova jinak.

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

Nemelo, ale jestlize to sou tyhle hruzy, tak je mozny ze tam dojde prave predevsim tim zapisem ke vzniku nejakych  nechutnych latenci ... hlavne bych se teda bal ty kombinace ruznych disku, kdy jeden odpovi klidne 100x driv nez jinej.

A viz vejs, kdybys tam nemel ten mdraid, ale btrfs raid, nejspis bys na to nenarazil, protoze by to snima pracovalo jako s jednotlivejma diskama. Rizika musis zvazit sam.

[maestrx]

Ahojte,

nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS). Jestli sem pochopil tak ctete data v nejakem nahodne rozmezi a vlastne netusite co za data na tom miste je. Dokau si pradstavit ze v tom 1TB bloku co ctete sou umistena metadata treba toho dm-crypt ktera se necim meni (timestamp, velikosti, etc...) a je uplne jedno jestli pisete do lokace 1TB, 3TB nebo 7TB. dm-crypt je aktivni nad celym 7TB svazkem a co tam presne dm-crypt dela zjistite az budete dokonale znat zdrojovy kod...

Osobne bych cely tenhle clanek prejmenoval, neco mi prepisuje data v dm-crypt kontejneru na jinem miste nez bych cekal. Urcite tohle nepovazuju za chybu cteni dokudk nedokazete ze mate nekonzistentni soubory....

Psal ste ze jsem porovnaval md5 zkopirovanych souboru behem migradce na tohle pole. Ma nejaky soubor ktery se od te doby nezmenil jine md5 nez behem migrace?

[Reklama]

[ByCzech]

nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS).

Jestli to chápu správně já, tak řeší pouze md0 (z napsaného předpokládám, že LVM a dm-crypt jsou v tu dobu neaktivní, protože číst blok dat ze zařízení, na kterém probíhají jiné operace výš by bylo opravdu úplně špatně a to samé si můžeme nasimulovat s jedním diskem, čtením z oddílu, když máme připojen souborový systém na tomto oddílu a něco s daty na FS pracuje) a z toho co tu píše, opakovaně čte blok dat ze zařízení /dev/md0. Občas při čtení toho stejného bloku dat to vyhodí jiný checksum = přečetla se jiná data.

Zhorší se to o to víc, když předem vyčtený (jiný) blok dat z /dev/md0 zapisuje zpět na stejné místo a opakuje test se čtením původního bloku dat. Data jsou častěji vyčtena jinak.

Nějak se mi nechce věřit, že by někdo byl takový hazardér a hrál si s blokovým zařízením výše popsaným způsobem, když by byly aktivní další vyšší vrstvy (LVM, dm-crypt, FS). Osobně předpokládám, že aktivní nejsou...

[Petr Kratochvíl]

nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS).

Jestli to chápu správně já, tak řeší pouze md0 (z napsaného předpokládám, že LVM a dm-crypt jsou v tu dobu neaktivní, protože číst blok dat ze zařízení, na kterém probíhají jiné operace výš by bylo opravdu úplně špatně a to samé si můžeme nasimulovat s jedním diskem, čtením z oddílu, když máme připojen souborový systém na tomto oddílu a něco s daty na FS pracuje) a z toho co tu píše, opakovaně čte blok dat ze zařízení /dev/md0. Občas při čtení toho stejného bloku dat to vyhodí jiný checksum = přečetla se jiná data.

Naprosto správně. Zapisuji (resp. čtu) pouze přímo na blokové zařízení /dev/md0, ne do souboru.

Nějak se mi nechce věřit, že by někdo byl takový hazardér a hrál si s blokovým zařízením výše popsaným způsobem, když by byly aktivní další vyšší vrstvy (LVM, dm-crypt, FS). Osobně předpokládám, že aktivní nejsou...

Správný předpoklad. Jak jsem psal, problém nastává už před zadáním cryptsetup luksOpen. tj. při testu nebyly aktivní vrstvy dm-crypt, LVM, ... Na ty se odvážím až si /dev/md0 získá zpátky důvěru.

[Petr Kratochvíl]

A viz vejs, kdybys tam nemel ten mdraid, ale btrfs raid, nejspis bys na to nenarazil, protoze by to snima pracovalo jako s jednotlivejma diskama. Rizika musis zvazit sam.

Opět zajímavá myšlenka. Díky i za předchozí rady.

Historie pole

Měl bych popsat historii toho pole /dev/md0. Měsíce jsou plus mínus 1 měsíc, jde hlavně o chronologii. Sry, stručněji to sepsat neumím.

• 2018 květen ... nákup 7 disků do PC s aktuálním Xubuntu, všechny prošly napoprvé plným badblocks testem. Vytvořeno md0, na něj umístěna vrstva dm-crypt/LUKS a přímo na ni jedno velké Btrfs (po starších zkušenostech jsem měl v Btrfs 100% důvěru). Od této chvíle pravidelně instalovány poslední stabilní verze kernelu (přes ukuu).
• 2018 červen - červenec ... naplnění daty = desítky milionů souborů, několik subvolumes (vč. snapshotů) a několik velkých souborů s bitovými kopiemi oddílů jiných disků (8 TB, 3 TB, 2 TB, ...).
• 2018 srpen ... ověření dat zkopírovaných z jiných disků (rsync -c na soubory a md5sum na image oddílů) ... všechny MD5 checksumy perfektně odpovídají, včetně checksumu 8 TB souboru (obsahujícího Btrfs oddíl ze staršího 8 TB disku). Vše funguje perfektně.
• 2018 září ... naimportovány tisíce subvolumes přes btrfs receive rozdílových streamů (current vs. parent subvolume), zadáno smazání několika velkých subvolume, btrfs receive dvou možná vadných streamů...
• 2018 září ... zděšení ... některé adresáře jsou nečitelné, u některých souborů nesedí checksum dat => 40 TB Btrfs volume is corrupted
• 2018 září ... přechod z Btrfs na LVM s cca dvaceti Btrfs oddílů (cenná data na read-only oddílech, nastaveno přes LVM: "lvchange -pr") a znova plnění z disků, které jsem ještě nesmazal
• 2018 říjen ... zděšení ... u některých oddílů checksum sedí, u některých ne
  
• 2018 listopad ... 1 ze 7 disků vykopnut z pole, hází chyby čtení, po restartu PC funguje normálně a nevykazuje sebemenší problém, vrátil jsem ho do pole
• 2018 listopad ... pole read-only (při testech zapisuji data na místa, odkud jsem je přečetl a nic jiného by zapisovat nemělo), snažím se najít příčinu

Moje hypotézy

• zhroucení FS v září ... nějaký Btrfs bug (nebo nedostatečná blbuvzdornost btrfs receive)? Měl jsem cca 100 milionů unikátních souborů, 2800 snapshotů, několik souborů nad 1 TB, denně jsem importoval cca 200 rozdílových btrfs streamů (inkr. zálohování btrfs send-receive), při tom jsem zadal smazání několika snapshotů velkých několik TB a naimportoval (btrfs receive) dva Btrfs streamy, ve kterých jsem se ručně povrtal (změnil parent uuid)
• vykopnutí disku v listopadu ... mohl to být následek, že se přečetla špatně nějaká důležitá data?
• chyby čtení při zápisu ... myslím si, že se změnil ovladač SATA řadiče nebo mdadm v nějaké cca říjnové verzi kernelu

Následující postup

• Zítra večer zkusím starší kernely
• Vypnu HPET v BIOSu (díky za tip)
• Zkusím parametry kernelu (díky za tipy):
  
  • libata.force=noncq
  • libata.force=1.5
  • libata.force=3.0
• Pokusím se aktualizovat firmware disků (imho buď nebudou existovat nebo to bude vyžadovat Windows, uvidíme)
• Zahledám, co ještě mi na forum.root.cz radili
• Otestuji, zda z toho lze alespoň vytáhnout data při vypnutých diskových cache. Buď to holt tak používat (btrfs by hodilo chybu kdyby se něco přečetlo špatně, neboť při čtení kontroluje checksumy dat, když se to nevypne) nebo našetřit na nové stejné pole a na něm to zkusit znova (a 2 pole pak mít na různých místech a používat jedno jako zálohu druhého)

[mtd]

Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

[ByCzech]

Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

Výkonná grafická karta s odběrem okolo 40-50W? Jako vážně? To by tam těch disků muselo být několikanásobně více, výkonná grafická karta bere aspoň 200-300 W.

[ByCzech]

Vypnu HPET v BIOSu (díky za tip)

HPET se dá vypnout i parametrem pro kernel hpet=disable, akorát nějak pořád nechápu čeho se tím má v souvislosti s popisovaným problémem docílit.

[Lol Phirae]

Docela se začínám bavit... Kup si 8 obřích disků, z nichž 5 se naprosto nehodí do RAIDu, nad to nahoď šifrování, a navrch přihoď filesystém, u kterého je notoricky známo, že když se posere, tak jsou data vyřízená, mnoha a doplň to o pár tisíc subvolumes a pár desítek milionů souborů. Hele, jestli se chceš zbavit přebytečných dat, tak je prostě normálně smaž, není potřeba trávit mládí s podobnými nesmyslnými experimenty.

Jinak až tě to omrzí, tak bych doporučil pořídit normální disky a nahodit třeba FreeBSD a ZFS RAID-Z2.

[mtd]

Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

Výkonná grafická karta s odběrem okolo 40-50W? Jako vážně? To by tam těch disků muselo být několikanásobně více, výkonná grafická karta bere aspoň 200-300 W.

počítá se cca 20W/disk, což při těch 6 discích dává nějakých 120W.

ten vývoj v čase, co OP popisuje, se dá vysvětlit klidně i odcházejícíma kondenzátorama na výstupu zdroje.

[RDa]

• 2018 listopad ... 1 ze 7 disků vykopnut z pole, hází chyby čtení, po restartu PC funguje normálně a nevykazuje sebemenší problém, vrátil jsem ho do pole

Najdi si duvod v syslogu - a podivej se, co se delo pred tim nez to mdraid vyhodil. Typicky je tam treba neco se SATA (coz muze byt napr. to chovani od SMR, ze to bude mit silene latence a jednou ten pohar trpelivosti sw raidu pretece).

Opravdu to nemuzes zkusit na jinem HW? To je totiz prvni co by se melo udelat, nez se trapit s potencialne vadnym hw. Ono totiz kdyby byl bug v sw/driveru, tak by se to tykalo vsech, tim ze se problem tyka jen tebe, tak to muze byt hw error.

Napajeni - doufam ze nemas 6 disku na jednom kabelu od zdroje, ale mas to vybalancovany po dvou, max trech. To same mechanicky - neRAID disky nemaji uplne rady vibrace, ktere delaj sousedni disky, takze bys to mel mit idealne rozlozeno od sebe a v ruznych uhlech. Vliv vibraci krasne ilustruje jedno video s nazvem ve stylu "do not shout on your disk array"

Ohledne zmeneneho 160kB bloku - zmena je pak trvala? Jaky je charakter dalsich chyb? (stejne misto, nebo ruzne misto? Lze identifikovat data, ktera tam jsou? (jestli udelas md5 pro kazdy 4kB blok, tak bys dokazal rict, odkud se tyto data vzali), pro rychle overeni staci treba "strings" pokud by to byl blok normalnich dat (coz asi nebude jestli mas ty data od dmcrypt).

[RDa]

Jinak až tě to omrzí, tak bych doporučil pořídit normální disky a nahodit třeba FreeBSD a ZFS RAID-Z2.

Chci videt jak spolehlive bude ZFS nad nespolehlivym diskem (vadnym kabelem), obzvlast v pripade, kdy takove zkriplene uloziste bude pouzivano pro slog