reklama

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

todul

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #90 kdy: 06. 12. 2018, 10:53:48 »
V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

Ze ja mam vzdy takove dobre tuseni :P
https://www.root.cz/zpravicky/poskozeni-souboroveho-systemu-mel-na-svedomi-planovac-oprava-jde-i-do-jadra-4-19/

Přesně mě to napadlo. Budiž to poučením, že na důležitá data není dobré používat neověřený kernel. Ono to má důvod, proč bývají v distribucích verze se zpoděním.

reklama


Lol Phirae

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #91 kdy: 06. 12. 2018, 11:03:38 »
V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

Ze ja mam vzdy takove dobre tuseni :P
https://www.root.cz/zpravicky/poskozeni-souboroveho-systemu-mel-na-svedomi-planovac-oprava-jde-i-do-jadra-4-19/

Přesně mě to napadlo. Budiž to poučením, že na důležitá data není dobré používat neověřený kernel. Ono to má důvod, proč bývají v distribucích verze se zpoděním.

O několik hodin později v rubrice Bazar: prodám několik zánovních zdrojů: 2x1000W, 2x1,5kW, 1x3kW. Zn.: Dobrá rada nad zlato.

 ;D 8)

ByCzech

  • *****
  • 1 541
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #92 kdy: 06. 12. 2018, 11:57:37 »
V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

Ze ja mam vzdy takove dobre tuseni :P
https://www.root.cz/zpravicky/poskozeni-souboroveho-systemu-mel-na-svedomi-planovac-oprava-jde-i-do-jadra-4-19/

Jenže jestli to chápu správně, musí to být kombinace FS a plánovače. Ale on test dělal bez FS. Testoval /dev/md0 rovnou...

Ale kdo ví, také jsem říkal, že určitá konzervativnost je lepší. I proto mám raději Debian

RDa

  • *****
  • 542
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #93 kdy: 06. 12. 2018, 12:36:31 »
Jenže jestli to chápu správně, musí to být kombinace FS a plánovače. Ale on test dělal bez FS. Testoval /dev/md0 rovnou...

Nechapes to spravne. Uzivatele EXT4 to reportuji protoze je to nejrozsirenejsi. IO scheduler pracuje rovnou nad fyzickym diskem (/dev/sd*), zatimco sw raid (/dev/md*) scheduler nema a filesystem uz vubec ne. Takze se to muze projevit i v pripade kdy mdraid pristupuje na disk device.
Kód: [Vybrat]
$ cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber none

$ cat /sys/block/md0/queue/scheduler
none

ByCzech

  • *****
  • 1 541
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #94 kdy: 06. 12. 2018, 13:18:59 »
Jenže jestli to chápu správně, musí to být kombinace FS a plánovače. Ale on test dělal bez FS. Testoval /dev/md0 rovnou...

Nechapes to spravne. Uzivatele EXT4 to reportuji protoze je to nejrozsirenejsi. IO scheduler pracuje rovnou nad fyzickym diskem (/dev/sd*), zatimco sw raid (/dev/md*) scheduler nema a filesystem uz vubec ne. Takze se to muze projevit i v pripade kdy mdraid pristupuje na disk device.
Kód: [Vybrat]
$ cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber none

$ cat /sys/block/md0/queue/scheduler
none

Tak v tom případě taky, napadlo mě to hned jak jsem četl https://www.root.cz/zpravicky/poskozeni-souboroveho-systemu-mel-na-svedomi-planovac-oprava-jde-i-do-jadra-4-19/ ale vyznívalo to tak, že to je v kombinaci s FS.

Jak říkám, konzervativnost kvůli stability je dobrý nápad.


trubicoid2

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #95 kdy: 07. 12. 2018, 13:58:30 »
navíc ty blk-mq schedulery jsou pořád o trochu pomalejší, než ty normální

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-IO-Schedulers

takže buď  scsi_mod.use_blk_mq=0 nebo  SCSI_MQ_DEFAULT=n

trubicoid2

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #96 kdy: 07. 12. 2018, 16:38:42 »
jinak jsem teď zkoušel přestartovat s libata.force=noncq a všechny /sys/block/*/device/queue_depth mají v sobě 1 a nejde do nich zapisovat

test rychlosti ukazuje, že libata.force=noncq a zapsat 1 do /sys/block/*/device/queue_depth je úplně stejný

trubicoid2

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #97 kdy: 07. 12. 2018, 19:05:53 »
tak jsem zkoušel znovu všechny kombinace write-cache a ncq pomocí tohoto skriptu (fio je asi lepší než ioping, ale vychází to stejně):

Kód: [Vybrat]
#!/bin/bash
DISK=sde #pozor, sem zapisuje
for w in 0 1
do
        for n in 1 31
        do
                echo "WC=" ${w} " NCQ=" ${n}
                for i in randread randwrite read write
                do
                        sync
                        sync
                        echo 3 > /proc/sys/vm/drop_caches
                        for d in /dev/sd?
                        do
                                j=`basename ${d}`
                                blockdev --flushbufs ${d}
                                hdparm -W ${w} -F -f ${d} 2>/dev/null >/dev/null
                                echo ${n} > /sys/block/${j}/device/queue_depth
                        done
                        echo -n "        " ${i} " : "
                        fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/${DISK} --bs=4k --iodepth=64 --size=128G --readwrite=${i} --runtim=140 --ramp_time=20 | grep iops
                done
        done
done

A výsledek je nakonec jinačí, než jsem čekal, takže jsem neměl pravdu.
Třeba WD 8TB UltraStar (HGST) (nešindelovej snad)

NCQ=1 , WC=0: read 558 iops, 251.7 MB/s, write 262 iops, 7.6 MB/s
NCQ=31, WC=0: read 1282 iops, 200.8 MB/s, write 420 iops, 11.1 MB/s
NCQ=1 , WC=1: read 556 iops, 251.7 MB/s, write 440 iops, 148.3 MB/s
NCQ=31, WC=1: read 1278 iops, 199.7 MB/s, write 453 iops, 89.1 MB/s

NCQ zvyšuje náhodné čtení, to jste čekali, ale kupodivu snižuje sekvenční čtení
zkoušel jsem echo check > /sys/block/md0/md/sync_action a je to opravdu bez NCQ o kapku rychlejší
btrfs scrub je bez NCQ pomalejší, on to asi nečte sekvenčně, ale spíš po souborech - náhodně

WC o dost sníží sekvenční zápis, kupodivu náhodný zápis s vypnutým WC, ale zapnutým NCQ je stejně vysoký

Se zapnutým WC NCQ spíše snižuje sekvenční zápis, podobně jako u čtení

takže asi záleží, asi se hodí při sekvenční zátěži NCQ vypnout (kontrola md z cronu, kopírování disku dd u zdroje i cíle)

trubicoid2

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #98 kdy: 14. 12. 2018, 15:12:04 »
ještě jsem teď zjistil v souvislosti s chybou blk_mq, že nejde jen o nastavení
Kód: [Vybrat]
scsi_mod.use_blk_mq=0 ale radši ještě k tomu
Kód: [Vybrat]
dm_mod.use_blk_mq=0 jelikož původní tazatel využívá minimálně dm-crypt, tak by to možná mohlo mít vliv

O několik hodin později v rubrice Bazar: prodám několik zánovních zdrojů: 2x1000W, 2x1,5kW, 1x3kW. Zn.: Dobrá rada nad zlato.

 ;D 8)

To mě pobavilo :-) Nebojte se, jakožto odborník spíše přes software než hardware hledám hardwarové řešení teprve až vyčerpám všechna možná softwarová řešení. A z nich pomohl downgrade kernelu.


  • Ustrnout na 4.19.0 (bez virtuálky).
  • Ustrnout na 4.19.0 a zkusit veškerou práci s Btrfs přesunout do virtuálky s akt. kernelem.
  • Akt. kernel (bez virtuálky) a vypnout NCQ.
  • Akt. kernel (bez virtuálky) a hned po bootu vypnout write cache příkazem hdparm -W 0.

na 4.19.0 bych nezůstával, když tak už třeba 4.14.85?

Díky vám a všem, kteří tu psali, že je lepší být trochu konzervativní, jsem se na konec rozhodl na 14 dní ustrnout na 4.14.86 (LTS) (vše nativně, bez virtuálky). Vše fungovalo perfektně bez přidávání parametrů kernelu, nevyskytly se žádné problémy se špatným čtením.

V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

Ze ja mam vzdy takove dobre tuseni :P
https://www.root.cz/zpravicky/poskozeni-souboroveho-systemu-mel-na-svedomi-planovac-oprava-jde-i-do-jadra-4-19/

Přesně tak, vypadá to, že problém popsaný na druhém odkazu výše je příčina mého problému. Po 14 dnech spokojeného běhu na kernelu 4.14.86 (LTS) jsem dnes zkusil reboot na 4.19.9. Oprava byla už v 4.19.8, pro jistotu jsem to zkontroloval v changelogu kernelu 4.19.8. Provedl jsem právě teď svůj oblíbený test čtení při zápisu přímo na /dev/md0 a 50x se načetlo 10 GiB se stejným md5 kontrolním součtem. Tj. vypadá to, že opravou v 4.19.8 je problém vyřešen.

Chystám se nyní zjistit, zda bych o něco zásadního přicházel na kernelu 4.14 místo 4.19 a pokud ne, tak bych se asi na 4.14 raději ještě vrátil. Předchozích 14 dní mi na něm nic nechybělo. Připomínám, že mě nové verze kernelu zajímají kvůli funkcím a opravám souborového systému Btrfs, ale dle Btrfs changelogu to vypadá, že alespoň na funkce by mi 4.14 mělo stačit, podporuje dokonce už i kompresní algoritmus zstd a důležité opravy jsou snad backportovány do 4.14.

Děkuji Vám všem za zajímavé a poučné příspěvky, které se tu objevily. Zjistil jsem, že některé věci nenapadly nejen mě, takže se z tohoto vlákna dozvědělo nové informace o Linuxu už několik lidí.

 

reklama