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

[Petr Kratochvíl]

Ahoj všichni,

předem díky za jakoukoliv konstruktivní radu, došly mi nápady.

Úvod

Mám 7 disků, každý z nich 8 TB s jedním velkým oddílem /dev/sd[bcdijkl]1, vytvářející přes mdadm RAID 6 jedno blokové zařízení /dev/md0 velké 40007 GB. Na celém /dev/md0 jsou data šifrovaná přes dm-crypt/LUKS, na kterém je LVM a na něm cca 20 oddílů ext4 a Btrfs, ale to je teď vedlejší, protože problém nastává již před připojením šifrovaného oddílu, tj. před provedením cryptsetup luksOpen /dev/md0 <dm_name>.

Stručný popis

Občas se čtou z mdadm RAID 6 pole /dev/md0 náhodná data, při současném zápisu se čtou velmi často náhodná data. Čtení z jednotlivých disků čte vždy stejná data, nikdy náhodná. Dle mdadm check je pole v pořádku.

Experiment č. 1: čtení z /dev/md0

Pokud zkusím číst opakovaně stejných 10 GiB z /dev/md0 od offsetu 1 TiB, mají data dle očekávání vždy stejný md5 checksum:

Kód: [Vybrat]

root@krato-space:~# for DEV in md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..6} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum )
; done ) ; done ; date
==== md0 ====
Po lis 26 12:13:26 CET 2018
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
Po lis 26 12:16:03 CET 2018

Experiment č. 2: čtení z /dev/md0

Občas je oproti očekávání ne vždy stejný md5 checksum (viz poslední):

Kód: [Vybrat]

root@krato-space:~# for DEV in md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..4} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum ) ; done ) ; done ; date
==== md0 ====
Po lis 26 22:20:25 CET 2018
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
1e434d76b388b0c21dec709a6d1b6d20  -
Po lis 26 22:22:08 CET 2018

Experiment č. 3: čtení z /dev/md0 při zápisu

A teď pozor. Pokud při čtení zároveň probíhá jakýkoliv zápis na jiném místě pole, přečtu z /dev/md0 občas nebo pokaždé data s jiným checksumem.

Říkám si, že mi leží těch 7 SATA kabelů volně uvnitř i vně case (disky leží vedle case, dovnitř se už nevešly), tak zda nechytají nějaké rušení nebo nezlobí některý ze dvou SATA řadičů, jenže pokud čtu data z disků zvlášť, je checksum vždy v pořádku. První a poslední čtveřice jsou checksumy 10 GiB čtených z /dev/md0, sedm čtveřic mezi nimi jsou čtení z jednotlivých disků:

Kód: [Vybrat]

root@krato-space:~# for DEV in md0 sdb1 sdc1 sdd1 sdi1 sdj1 sdk1 sdl1 md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..4} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum ) ; done ) ; done ; date
==== md0 ====
Po lis 26 20:03:03 CET 2018
31a877f49150e0f6452b843d81a8c88d  -
9b2010d3fb1344139f9eba21ad309b7b  -
e11e03afc313e5de46105f15ffc33665  -
9bfde541773fc0ef03a4b1ff1c45621c  -
==== sdb1 ====
Po lis 26 20:08:15 CET 2018
7fdc1658562a2ecd4d676bf656c973a7  -
7fdc1658562a2ecd4d676bf656c973a7  -
7fdc1658562a2ecd4d676bf656c973a7  -
7fdc1658562a2ecd4d676bf656c973a7  -
==== sdc1 ====
Po lis 26 20:26:35 CET 2018
7c671e9e47fdb2604e2ecfcea6009218  -
7c671e9e47fdb2604e2ecfcea6009218  -
7c671e9e47fdb2604e2ecfcea6009218  -
7c671e9e47fdb2604e2ecfcea6009218  -
==== sdd1 ====
Po lis 26 20:45:38 CET 2018
bb14e932be6c2ae2751404a997c24712  -
bb14e932be6c2ae2751404a997c24712  -
bb14e932be6c2ae2751404a997c24712  -
bb14e932be6c2ae2751404a997c24712  -
==== sdi1 ====
Po lis 26 20:56:27 CET 2018
4fb8ad4d063fff30e39ff64205713952  -
4fb8ad4d063fff30e39ff64205713952  -
4fb8ad4d063fff30e39ff64205713952  -
4fb8ad4d063fff30e39ff64205713952  -
==== sdj1 ====
Po lis 26 21:07:44 CET 2018
00528ce93f8c54882d022f976004442f  -
00528ce93f8c54882d022f976004442f  -
00528ce93f8c54882d022f976004442f  -
00528ce93f8c54882d022f976004442f  -
==== sdk1 ====
Po lis 26 21:38:04 CET 2018
33d73ace82b8bc28fd284fc32c216039  -
33d73ace82b8bc28fd284fc32c216039  -
33d73ace82b8bc28fd284fc32c216039  -
33d73ace82b8bc28fd284fc32c216039  -
==== sdl1 ====
Po lis 26 21:45:57 CET 2018
842b476f2973e16403f3fc1a031b968a  -
842b476f2973e16403f3fc1a031b968a  -
842b476f2973e16403f3fc1a031b968a  -
842b476f2973e16403f3fc1a031b968a  -
==== md0 ====
Po lis 26 21:53:30 CET 2018
e08baf910b005f1f001c8258330a0637  -
4ce735569e51ad0e75d4775a0a2e565b  -
d740da3b4b7a2167ca369c9b00efe6d2  -
75f0c751bbd8f95b0ed6d49c379f9ff8  -
Po lis 26 22:06:22 CET 2018

Konkrétně u tohoto experimentu č. 3 jsem prováděl zápis tím způsobem, že jsem na jiném offsetu 1 GiB načetl 100 GiB dat do souboru na systémovém SSD disku:

Kód: [Vybrat]

dd if=/dev/md0 bs=1M count=102400 skip=1024 status=progress of=/root/md0_offset-1024M_size-102400M-2018-11-26-1308.bin

A tato data jsem pak při testu čtení v cyklu zapisoval zpět přesně tam, odkud jsem je přečetl:

Kód: [Vybrat]

for i in {1..10} ; do dd if=/root/md0_offset-1024M_size-102400M-2018-11-26-1308.bin bs=1M count=102400 seek=1024 status=progress of=/dev/md0 ; done

Chyba software vs. hardware

Nezkouším koupit nový hardware (kabely, case, zdroj, disky, ...), protože při čtení z jednotlivých disků zvlášť nikdy tento problém nepozoruji.

Vyloučení nekonzistence dat RAID 6

Už se určitě chystáte poradit mdadm check a mdadm resync. To by to ale bylo příliš jednoduché.

Před testy výše jsem provedl postupně:

• mdadm resync ... našel 3688 chyb (dle čísla v /sys/block/md0/md/mismatch_cnt)
• mdadm check ... našel 0 chyb (dle čísla v /sys/block/md0/md/mismatch_cnt)

Verze software


root@krato-space:~# lsb_release --description
Description:    Ubuntu 18.04.1 LTS

root@krato-space:~# uname --all
Linux krato-space 4.19.2-041902-generic #201811132032 SMP Tue Nov 13 20:34:19 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

root@krato-space:~# mdadm --version
mdadm - v4.1-rc1 - 2018-03-22

[Reklama]

[j]

Vypni cache jednotlivych disku, vykon ti teda dost padne, ale aspon na test to zkus.

[RDa]

Cteni 10GB z /dev/sdX+1GB neodpovida lokaci ktera je z tech sestavenych disku do /dev/mdX+1GB

A pokud pises "provadi se zapis na jine misto", tak v pripade ze mas nad tim LVM, je zcela mozne ze ty bloky se ti prekryvaj a meni se ti /dev/mdX prave tam kde to necekas.

[Petr Kratochvíl]

Vypni cache jednotlivych disku, vykon ti teda dost padne, ale aspon na test to zkus.

Díky za tip!

Klobouk dolů, to by mě nenapadlo.

Cache disků jsem vypnul takto příkazem hdparm v cyklu:

Kód: [Vybrat]

for DEV in sdb1 sdc1 sdd1 sdi1 sdj1 sdk1 sdl1 ; do hdparm -W 0 /dev/$DEV ; done

A zkusil znova testy čtení při zápisu (20x čtení stejných 10 GiB při kontinuálním zápisu na jiný offset). Testy postupně dopadly:

• Vypnutí diskových cache.
• Čtení při zápisu: OK
• Zapnutí diskových cache.
• Čtení při zápisu: náhodná data
• Vypnutí diskových cache.
• Čtení při zápisu: OK

Pro info: čtení při zápisu je vypnutou cache cca 5x pomalejší, s čímž počítáme.

Prosím, jaká je tedy prvotní příčina a jak postupovat dál?

[Petr Kratochvíl]

Cteni 10GB z /dev/sdX+1GB neodpovida lokaci ktera je z tech sestavenych disku do /dev/mdX+1GB

To je pravda. Šlo mi hlavně o čtení z jiného místa než kam se zapisuje. Jiné testy ukázaly, že asi vůbec nezáleží na offsetu, problém se projevil stejně i při jiných offsetech.

A pokud pises "provadi se zapis na jine misto", tak v pripade ze mas nad tim LVM, je zcela mozne ze ty bloky se ti prekryvaj a meni se ti /dev/mdX prave tam kde to necekas.

Chápu přesně pointu, ale LVM mám na šifrovaném oddílu, který není připojený. Tj. nepoužil jsem cryptsetup luksOpen a problém se přesto projevuje. Pro jistotu uvedu vrstvy jak leží na sobě (jsem otevřen radám na vylepšení):

• fyzicky 7 disků 8 TB
• na každém disku partitiona přes celý disk /dev/sdX1
• mdadm RAID 6 přes všech 7 partitions (vytváří 40 TB blokové zařízení /dev/md0)
• dm-crypt/LUKS
• LVM Physical Device
• LVM Volume Group (sestává se jen z /dev/md0)
• LVM Logical Volumes
• ext4 a Btrfs na LVM logických oddílech (některé r, některé rw; některé snapshoty)
• Btrfs oddíly mají vždy 1 nebo více subvolumes (když už dělíme do vrstev)

Problém se projevuje před zadáním hesla, tj. na prvních 3 vrstvách:

• fyzicky 7 disků 8 TB
• na každém disku partitiona přes celý disk /dev/sdX1
• mdadm RAID 6 přes všech 7 partitions (vytváří 40 TB blokové zařízení /dev/md0)

[Reklama]

[RDa]

Jako chova se ti to hodne divne.

Zkus namisto cteni pouzit kopirovani (do RAM - /dev/shm) a nad tim md5, pokud je stejny jako predesla kopie tak se udela cteni znova. Jen musis mit v ram dve kopie stejneho regionu. Az ti to zahlasi ze md5 nesouhlasi, tak ty dva soubory porovnas.. a zjistis co se s tim vlastne stalo - bud se zmeni 1 bit, nejaky sektor, nebo cely raid stripe.

Tip pro porovnani dvou X GB souboru: udelej si skript co projede pres 1M bloky md5 a pak diff tech dvou seznamu md5. Vadnej chunk pak extrahuj, hexdump -Cv a pak diff 1.hex 2.hex (takto jsem nasel 1 flipnuty bit v 18G instalacce).

[kkt1]

Co rika opakovany mdadm resync? Jake jsou to disky a jaky je to radic?

[j]

Chmm ... prejit na nejakej HW raid. Totiz tohle vypada na nejakej hlubsi problem v tom SW raidu, s tim tezko neco nejak rychle udelas. Podle me se to bude projevovat prave jen kdyz mas vic disku, takze mnoztvi lidi ktery by to byly schopny testovat nebude velky a navic to muze souviset i s chovanim konkretnich disku. Rek bych ze to bude neco na tema potvrzovani transakci/invalidace cache/...

Pripadne jeste muzes testnout jiny verze kernelu.

[Madafa]

Vadná ram nebo chyba v software.
Řešení?
Nechovat se jako pako a požít Arecu 

[dustin]

IMO je nejjednodušší řešení přejít u takhle velkého pole na ZFS (+ samozřejmě ECC paměti).

[kkt1]

 

[ByCzech]

Cache disků jsem vypnul takto příkazem hdparm v cyklu:
...

Pro info: čtení při zápisu je vypnutou cache cca 5x pomalejší, s čímž počítáme.

Prosím, jaká je tedy prvotní příčina a jak postupovat dál?

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

[ByCzech]

Vadná ram nebo chyba v software.

Jasně a vadnou ram nebo chybu v software vyřeší vypnutí HW cache na disku

[Jose]

Hledal bych prvotní příčinu v těch dvou SATA řadičích, nemusí si rozumět s ovladači pokus mají probíhat operace současně na obou.

[Petr Kratochvíl]

Jako chova se ti to hodne divne.

Zkus namisto cteni pouzit kopirovani (do RAM - /dev/shm) a nad tim md5, pokud je stejny jako predesla kopie tak se udela cteni znova. Jen musis mit v ram dve kopie stejneho regionu. Az ti to zahlasi ze md5 nesouhlasi, tak ty dva soubory porovnas.. a zjistis co se s tim vlastne stalo - bud se zmeni 1 bit, nejaky sektor, nebo cely raid stripe.

Tip pro porovnani dvou X GB souboru: udelej si skript co projede pres 1M bloky md5 a pak diff tech dvou seznamu md5. Vadnej chunk pak extrahuj, hexdump -Cv a pak diff 1.hex 2.hex (takto jsem nasel 1 flipnuty bit v 18G instalacce).

Díky za tip a donucení k testu, který na konec nebylo zas tak složité vytvořit. Výsledek prozatím jednoho nalezení rozdílu:

Rozdíl ve dvou po sobě jdoucích načteních je na offsetu 830,5 MiB a je dlouhý přesně 160 KiB (liší se celý tento blok). Když vydělíme velikost rozdílu číslem 5 (protože je 7 disků z RAIDu 6 => 7-2=5), vyjde nám hezké IT-kulaté číslo:

160 KiB / 5 = 32 KiB

Což může, ale nemusí být náhoda.

Podle příkazu mdadm -E /dev/sdb1 | grep "Chunk Size" je mdadm chunk size na mdadm disku: 256 KiB

Co z toho vyplývá?

O víkendu mohu zkusit downgrade kernelu (což bych už jen kvůli Btrfs nerad natrvalo).