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

Lol Phirae

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #75 kdy: 01. 12. 2018, 22:00:02 »
A neni mi jasne, zda jste taky vyzkousel jiny zdroj.

To už tady dlouho nebylo. Ukončili jsme to tuším na 3kW. Sicher ist sicher.  ;D


todul

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #76 kdy: 02. 12. 2018, 01:48:07 »
Mimochodem, kde se tam vzaly takhle nové verze kernelu?

V 18.04 LTS je nejnovější 4.15.0-39

To jsou nějaké neoficiální verze? Není lepší se držet těch podporovaných?

ByCzech

  • *****
  • 1 862
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #77 kdy: 02. 12. 2018, 03:03:25 »
Ohledně výkonu asi lepší bude 4.19.0, ale kvůli používání Btrfs bych preferoval pravidelně aktualizovat kernel.

Nejnovější neznamená vždy nejlepší. Určitá konzervativnost naopak vůbec není na škodu.

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

Já osobně bych nechal 1. dokud nebudu moct vyřešit výměnu disků.

"No Newer Firmware Available"

A co další disky z poli a firmware? Nevíme kterých se to týká. Pravděpodobnější je problém v šindelových, ale jeden nikdy neví.

Ok, klidně raďte, jak zkoumat. Zkusil jsem projít changelog kernelu 4.19.1, ale nenašel jsem tam nic na klíčová slova "ncq" či "sata":

No nejlépe se zkoumají patche, po kterém to začne dělat. Ale to je na dost dlouho...

Možná nějak ověřit, zda se to skutečně týká jen těch 4 disků EXOS. Jak?

To je taky na dlouhé zimní večery. Navíc by se musely dát data pryč z pole a přeskládávat ho...

Je to podobné, jako když je v kernelu blacklist na některé featury např. SSD jednotek (pamatujete na ztrácející se data i SSD Samsungu při zapnutém Queued Trim? Ve Windows se to nedělo, protože ho neuměly. V Linuxu se chyba okamžitě projevila, protože používal featuru, kterou měly jednotky dle specifikace zvládat, protože hlásily že danou specifikaci umí).

Zajímavé.

Viz https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L4397

takových featur různých jednotek je na blacklistu docela dost.

Vedle PC mám NAS a v něm 2x Seagate IronWolf 8TB. Pokud to nejsou šindele, tak bych je s dvěma šindeli v poli prohodil. A pak bych si raději při koupi disku vždy připlatil, např. na Western Digital WD Red 8TB. Máte někdo nějaké další doporučení na 8 TB disk (snad tím nespustím flame war)?

IronWolfy nejspíš šindelové nejsou, Seagate je doporučuje do polí, ale ruku do ohně bych za to nedal. Redy jsou fajn, já mám ještě v oblibě Toshiby. Obojí jsou skvělé držáky, Toshiby jsou výkonnější - 7200 rpm ;).

ByCzech

  • *****
  • 1 862
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #78 kdy: 02. 12. 2018, 03:06:13 »
A neni mi jasne, zda jste taky vyzkousel jiny zdroj.

To už tady dlouho nebylo. Ukončili jsme to tuším na 3kW. Sicher ist sicher.  ;D

To už není normální toto ;D ;D ;D odkud se ti radílci s těmi zdroji berou? Mám návrh: <sarkasmus>Co takhle koupit každému disku vlastní 1kW zdroj?</sarkasmus>

ByCzech

  • *****
  • 1 862
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #79 kdy: 02. 12. 2018, 03:31:43 »

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

no já naznačoval, že 3 a 4 jsou v důsledku stejný, obě varianty vypnou write-cache, zpomalíš zápis

Opravdu si nemyslím, že se tohle děje. NCQ je vypínatelné zvlášť. Cache jednotky je něco jiného. Běžně se dá dát jednotka podporující NCQ na řadič, který NCQ nepodporuje a Write cache je aktivní. Jde to vidět i na výše uvedeném odkazu na blacklist featur. U některých jednotek se NCQ vypíná tímto blacklistem, protože je s NCQ pomalejší, než bez NCQ. S write cache to nemá co dělat.

Viz https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L4453

Jinak noncq se nemusí vypnout pro všechny jednotky, dá se vypnout jen pro konkrétní. Asi by to stálo za pokus. Tím by se nejspíš přišlo na to, která(é) jednotka(y) zlobí.

Viz https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt

odkaz na to nemám, ale si to zkuste, jak obě metody stejně sníží výkon při zápisu,

NCQ zrychluje random access, protože umožňuje, aby si jednotka přeuspořádala pořadí požadavků (čtecích i zápisových) tak, aby se vybavily rychleji, než kdyby se řešili postupně.

pro ty šindeláře to musí být smrtelný

To určitě. Stejně jako jejich provoz v poli.


trubicoid2

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #80 kdy: 02. 12. 2018, 12:35:00 »
Opravdu si nemyslím, že se tohle děje. NCQ je vypínatelné zvlášť. Cache jednotky je něco jiného. Běžně se dá dát jednotka podporující NCQ na řadič, který NCQ nepodporuje a Write cache je aktivní. Jde to vidět i na výše uvedeném odkazu na blacklist featur. U některých jednotek se NCQ vypíná tímto blacklistem, protože je s NCQ pomalejší, než bez NCQ. S write cache to nemá co dělat.

Viz https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L4453

no mě to popravdě taky zaskočilo, z pohledu uživatele a dokumentů je ncq a write-cache opravdu jiná věc, otázka je, jak je to implementováno uvnitř disku.

se ukázalo, že vypnutí ncq zároveň vypne write-cache. proč to nevím, ale zkuste si sami. zajímavé by to bylo pro ty smr disky, ale tam ani nevím, jak přesně měřit write rychlost, protože mívají 16GB normálního zápisu a pak to jde do šindele...

(pozor, přepisuje data na partici, zde sdb1)

Kód: [Vybrat]
echo 1 > /sys/block/sdb/device/queue_depth
hdparm -W 1 /dev/sdb
ioping -w100 -R -D /dev/sdb1
ioping -w100 -RL -D /dev/sdb1
ioping -w100 -RWWW -D /dev/sdb1
ioping -w100 -RLWWW -D /dev/sdb1

teď jsem všechny 4 kombinace (queue_depth=1,31; W =0,1) zkoušel na starý Seagate Baracude 500GB a tam to kupodivu nedělá vůbec žádný rozdíl

jestli bude čas zkusím na WD, tam právě poklesl stejně výkon při zápisu při queue_depth=1 stejně jako W=0, na čtení (a to ani náhodný) to vliv nemělo
 
Jinak noncq se nemusí vypnout pro všechny jednotky, dá se vypnout jen pro konkrétní. Asi by to stálo za pokus. Tím by se nejspíš přišlo na to, která(é) jednotka(y) zlobí.

Viz https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
[\quote]

no tak za chodu vypínat a zapínat přes /sys/block/sdb/device/queue_depth je praktičtější, nemusím restartovat



NCQ zrychluje random access, protože umožňuje, aby si jednotka přeuspořádala pořadí požadavků (čtecích i zápisových) tak, aby se vybavily rychleji, než kdyby se řešili postupně.


leda teoreticky, ve skutečnosti ne. viz. benchmark výše. prostě implementace ncq v discích stojí za pendrek, kdyby to nevypínalo write-cache, tak by to bylo lepší vypnout

ByCzech

  • *****
  • 1 862
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #81 kdy: 02. 12. 2018, 14:38:34 »
Opravdu si nemyslím, že se tohle děje. NCQ je vypínatelné zvlášť. Cache jednotky je něco jiného. Běžně se dá dát jednotka podporující NCQ na řadič, který NCQ nepodporuje a Write cache je aktivní. Jde to vidět i na výše uvedeném odkazu na blacklist featur. U některých jednotek se NCQ vypíná tímto blacklistem, protože je s NCQ pomalejší, než bez NCQ. S write cache to nemá co dělat.

Viz https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L4453

no mě to popravdě taky zaskočilo, z pohledu uživatele a dokumentů je ncq a write-cache opravdu jiná věc, otázka je, jak je to implementováno uvnitř disku.

S tím souhlasím. Implementace se určitě bude lišit napříč různými jednotkami.

se ukázalo, že vypnutí ncq zároveň vypne write-cache. proč to nevím, ale zkuste si sami. zajímavé by to bylo pro ty smr disky, ale tam ani nevím, jak přesně měřit write rychlost, protože mívají 16GB normálního zápisu a pak to jde do šindele...

Jj, s šimdelama je prostě potíž.

se ukázalo, že vypnutí ncq zároveň vypne write-teď jsem všechny 4 kombinace (queue_depth=1,31; W =0,1) zkoušel na starý Seagate Baracude 500GB a tam to kupodivu nedělá vůbec žádný rozdíl

No právě. Navíc podle mě je nastavení úrovní ve frontě něco jiného, než vypnutí podpory NCQ. Jednotlivé implementace se nejspíše budou opět lišit podle konkrétní jednotky. Kdo ví jak se chová jednotka, které je hlášena podpora NCQ, ale délka fronty je jedna oproti tomu, kdy je jednotce hlášena nepodpora NCQ. Disky mají hromadu optimalizací vnitřně.

se ukázalo, že vypnutí ncq zároveň vypne write-
jestli bude čas zkusím na WD, tam právě poklesl stejně výkon při zápisu při queue_depth=1 stejně jako W=0, na čtení (a to ani náhodný) to vliv nemělo

Otázka právě je, co to s touto konkrétní jednotkou udělá, když se jí nahlásí podpora NCQ a pak srazí úrovně fronty na jednu položku. :) Klidně může být něco, s čím programátor firmware nepočítal, protože se to běžně nevyskytuje a výkon jde do háje podobně jako když se vypne cache.

trubicoid2

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #82 kdy: 02. 12. 2018, 14:44:44 »
to ncq queue je od začátku blbě implementovaný, nejde tam poslat 0 ani 32  :o >:(
1 to vypíná a 31 je plný ncq, si klidně při benchmarku restartuj s noncq, dopadne to stejně

naseptavac

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #83 kdy: 02. 12. 2018, 22:00:36 »
To už není normální toto ;D ;D ;D odkud se ti radílci s těmi zdroji berou? Mám návrh: <sarkasmus>Co takhle koupit každému disku vlastní 1kW zdroj?</sarkasmus>

Od hluboke myslenky "5W is enough for everything" jsi dosel az k ubervtipnym kotrmelcum, super.

No ale myslet si, ze vsechny zdroje, na ktere nejaky cinan nalepi cosi o 400W se chovaji stejne a nemuzou se podelat (na rozdil od software) je priznakem opravdu vysoke inteligence a mnohaletych zkusenosti, respect.

Nicmene vsechno podstatne uz bylo recene, takze good luck puvodnimu tazateli.

Lol Phirae

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #84 kdy: 02. 12. 2018, 22:08:02 »
No ale myslet si, ze vsechny zdroje, na ktere nejaky cinan nalepi cosi o 400W se chovaji stejne a nemuzou se podelat

Jojo, a ještě se důmyslně podělávají v závislosti na verzi kernelu.  ;D

naseptavac

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #85 kdy: 02. 12. 2018, 22:09:29 »
No ale myslet si, ze vsechny zdroje, na ktere nejaky cinan nalepi cosi o 400W se chovaji stejne a nemuzou se podelat

Jojo, a ještě se důmyslně podělávají v závislosti na verzi kernelu.  ;D

Soubeh spicek zateze umi zazraky. Ale kdo chce kam, pomozme mu tam.

Lol Phirae

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #86 kdy: 02. 12. 2018, 22:26:33 »
No ale myslet si, ze vsechny zdroje, na ktere nejaky cinan nalepi cosi o 400W se chovaji stejne a nemuzou se podelat

Jojo, a ještě se důmyslně podělávají v závislosti na verzi kernelu.  ;D

Soubeh spicek zateze umi zazraky.

Jasně, jedná se o celoplanetární spyqnutí výrobců nekvalitních zdrojů se šindeláři.  :o ;D ::)

naseptavac

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #87 kdy: 02. 12. 2018, 22:33:05 »
Jasně, jedná se o celoplanetární spyqnutí výrobců nekvalitních zdrojů se šindeláři.  :o ;D ::)

On zkousel vice zdroju nebo jen zvanis?

Tester

Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #88 kdy: 02. 12. 2018, 23:03:23 »
Este by som sa vyskusal pohrat s io schedulermi a pre zaciatok by som zvolil deadline scheduler

RDa

  • *****
  • 2 783
    • Zobrazit profil
    • E-mail
Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)
« Odpověď #89 kdy: 06. 12. 2018, 09:29:43 »
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/