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 540
    • 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

  • *****
  • 541
    • 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 540
    • 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)

 

reklama