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

[kkt1]

Chtělo by ta tvrzení něčím podložit a nejen napsat "bude efekt horší" a podobné cancy. Úplně normálně si tu vymýšlíte.

Ten tvuj graf ukazuje prumerne spotreby (prime mereni) nejakejch disku pri ruznych typech operaci. Je-li prumerna spotreba az 10W, spickova bude vic. Proudovy naraz mujze byt proste vetsi a zdroj je musi ustat.

BTW Nejdrive napises 5W, pak sem das graf nejakejch odpadkovejch disku, kde je az 10W a ted to chces necim podlozit? Strc si tu svou aroganci nekam a pak si to misto vypodloz diskem. Treba ti hemeroidy prozradi, zda se takhle ohriva vec se spotrebou 3,5W.

Spickova spotreba bude vic, ale ne 200W na disk. Samotny 1000W zdroj utahne 96 disku se spotrebou 6W bez jakehokoliv problemu.

[Reklama]

[ByCzech]

Chtělo by ta tvrzení něčím podložit a nejen napsat "bude efekt horší" a podobné cancy. Úplně normálně si tu vymýšlíte.

Ten tvuj graf ukazuje prumerne spotreby (prime mereni) nejakejch disku pri ruznych typech operaci. Je-li prumerna spotreba az 10W, spickova bude vic. Proudovy naraz mujze byt proste vetsi a zdroj je musi ustat.

BTW Nejdrive napises 5W, pak sem das graf nejakejch odpadkovejch disku, kde je az 10W a ted to chces necim podlozit? Strc si tu svou aroganci nekam a pak si to misto vypodloz diskem. Treba ti hemeroidy prozradi, zda se takhle ohriva vec se spotrebou 3,5W.

Tazatel má v poli mimo jiné disky WD RED 8 TB. Ty v grafu jsou. To že tam jsou i jiné snad ničemu nevadí. To že WD Black disky mají větší spotřebu, protože jsou laděné na výkon se ví, ale k tématu to má maximálně to, že ani takový disk nepřekračuje v zátěži 10W, mtd tady psal o 20W na disk, což není očividně pravda, protože i tyhle disky nedosahují ani polovinu. Až budete skládat pole o větších desítkách disků, třeba budete mít taky ponětí o tom, kolik to bere a jak dimenzované zdroje jsou k tomu potřeba. 7 disků prostě nebere stejně jako výkonná grafická karta i kdyby to byly ty 10W WD Black, což byl původní příspěvek, na který jsem ohledně spotřeby disků reagoval.

PS: Aroganci a k tomu hulvátství tady předvádíte vy.

[naseptavac]

Tazatel má v poli mimo jiné disky WD RED 8 TB. Ty v grafu jsou. To že tam jsou i jiné snad ničemu nevadí. To že WD Black disky mají větší spotřebu, protože jsou laděné na výkon se ví, ale k tématu to má maximálně to, že ani takový disk nepřekračuje v zátěži 10W, mtd tady psal o 20W na disk, což není očividně pravda, protože i tyhle disky nedosahují ani polovinu. Až budete skládat pole o větších desítkách disků, třeba budete mít taky ponětí o tom, kolik to bere a jak dimenzované zdroje jsou k tomu potřeba. 7 disků prostě nebere stejně jako výkonná grafická karta i kdyby to byly ty 10W WD Black, což byl původní příspěvek, na který jsem ohledně spotřeby disků reagoval.

PS: Aroganci a k tomu hulvátství tady předvádíte vy.

Proc se vyjadrujes k HW zalezitosem, kdyz tomu vubec nerozumis? Az budes uspesne lecit pc s vice disky, ktere nejaky znalec stazenych grafu poskladal, prijd. O graficke karte jsem se vubec nezminoval, ale jestli to je tvoje obsese, tak ok.

[kkt1]

Tazatel má v poli mimo jiné disky WD RED 8 TB. Ty v grafu jsou. To že tam jsou i jiné snad ničemu nevadí. To že WD Black disky mají větší spotřebu, protože jsou laděné na výkon se ví, ale k tématu to má maximálně to, že ani takový disk nepřekračuje v zátěži 10W, mtd tady psal o 20W na disk, což není očividně pravda, protože i tyhle disky nedosahují ani polovinu. Až budete skládat pole o větších desítkách disků, třeba budete mít taky ponětí o tom, kolik to bere a jak dimenzované zdroje jsou k tomu potřeba. 7 disků prostě nebere stejně jako výkonná grafická karta i kdyby to byly ty 10W WD Black, což byl původní příspěvek, na který jsem ohledně spotřeby disků reagoval.

PS: Aroganci a k tomu hulvátství tady předvádíte vy.

Proc se vyjadrujes k HW zalezitosem, kdyz tomu vubec nerozumis? Az budes uspesne lecit pc s vice disky, ktere nejaky znalec stazenych grafu poskladal, prijd. O graficke karte jsem se vubec nezminoval, ale jestli to je tvoje obsese, tak ok.

dokazes pochopit, ze 10disku nevyvola 200W peak? Mam tady 12 sasu v boxu, dle dokumentace maji peak 10W. Vis kolik berou u zapnuti? cca 137W. To by musel mit v tom servru nejaky 400w zdroj s nejakou debilni krivkou aby mu to zdechlo. Samozrejme ucinost zdroje ktery bude mit 5 let a bude zadrbany od prachu bude jina nez noveho, ale nepredpokladame ze tam ma 400w zdroj, tudiz tve znalosti z lecby PC s vice disky jsou uplne k ho*nu.

[Petr Kratochvíl]

Pokusím se vrátit pozornost k původnímu problému:

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

Včera večer a dnes v noci jsem provedl experimenty (víc jsem jich zatím nestihl) s těmito výsledky:

Experiment: Starší kernely

Pozn.: Instalované v Xubuntu 18.04 přes nástroj ukuu.

Test na /dev/md0 čtení 10x 10 GiB při kontinuálním zápisu.

Žádné parametry kernelu jsem nepřidával, pouze zkouším starší verze (a jednu novější).

• 4.17.0-041700.201806041953 ... OK
• 4.19.0-041900.201810221809 ... OK (ještě plánuji ověřit delším testováním)
• 4.19.1-041901.201811041431 ... čte chybně
• 4.19.2-041902.201811132032 ... čte chybně (na této verzi jsem si všiml problému)
• 4.19.5-041905.201811271131 ... čte chybně
• 4.20.0-042000rc4.201811252331 ... čte chybně (verze RC4)

Experiment: Parametry kernelu (aktuální stabilní = 4.19.5)

Test na /dev/md0 čtení 10x 10 GiB při kontinuálním zápisu.

Použit aktuálně nejnovější stabilní kernel, tj.: 4.19.5-041905.201811271131

• (žádný parametr nepřidán) ... čte chybně
• hpet=disable ... čte chybně
• libata.force=noncq ... OK
• libata.force=1.5 ... čte chybně
• libata.force=3.0 ... čte chybně

Závěr

Pokud nedošlo k chybě měření, tak pomáhá jedno z:

• Downgrade kernelu na 4.19.0
• Nechat vypnuté NCQ parametrem libata.force=noncq

Další postup

Která varianta je lepší, zůstat na 4.19.0 nebo vypnout NCQ?

Jak moc špatné by bylo mít trvale vypnuté NCQ?

Napadá vás nějaké lepší řešení, které by stálo za pokus?

Napadá vás jakými dalšími experimenty najít počáteční příčinu?

Pokud se jedná o bug v kernelu, který by se mohl projevovat u dalších uživatelů, jsem ochotný i přes workaroundy výše nadále pátrat po příčině. Jen raďte, co mám dál zkusit.

Jinak podotýkám, že by chtělo experimenty výše ještě ověřit přečtením více dat než 10x 10 GiB, což mám v plánu minimálně u kernelu 4.19.0 (bez přidaných parametrů) a u aktuálního kernelu s vypnutým NCQ.

[Reklama]

[ByCzech]

Závěr

Pokud nedošlo k chybě měření, tak pomáhá jedno z:

• Downgrade kernelu na 4.19.0
• Nechat vypnuté NCQ parametrem libata.force=noncq

Další postup

Která varianta je lepší, zůstat na 4.19.0 nebo vypnout NCQ?

Jak moc špatné by bylo mít trvale vypnuté NCQ?

Tipuji, že 4.19.0 bude lepší ohledně výkonu, než vypínat NCQ. Osobně jsem čekal, že z těch pokusů s kernelem zaberou přesně tyhle věci...

Napadá vás nějaké lepší řešení, které by stálo za pokus?

Upgrade firmware.

Napadá vás jakými dalšími experimenty najít počáteční příčinu?

Osobně jsem si v podstatě z nových informací jist, že chyba je ve firmware některého z disků (nejspíše těch šindelových). Honbou za zlepšením výkonu mají nejspíše nějakou optimalizaci, která v běžném provozu funguje, ale ve složitější konfiguraci a s novějším kernelem naopak způsobuje bug (ve firmware), který vrátí v určitých případech za použití NCQ jiná data z cache, která si myslí, že jsou ta správná. Jiná verze kernelu to řeší nejspíše proto, že byl změněn algoritmus práce s NCQ. Možná by to stálo za prozkoumání.

Každopádně řešení je jak jsem již psal dříve zkusit nahrát do disků nový firmware, je možné, že dost pravděpodobné, že chyba už v něm nebude, s velmi podobně chovající se věcí jsem se už setkal a firmware to řešil. A ano také to bylo v poli, se samostatným diskem se chyba neprojevila nikdy.

Pokud se jedná o bug v kernelu, který by se mohl projevovat u dalších uživatelů, jsem ochotný i přes workaroundy výše nadále pátrat po příčině. Jen raďte, co mám dál zkusit.

Osobně si myslím, že to není bug, ale buď se změnila algoritmu při práci, která se projeví při zapnutém NCQ nebo kernel začal využívat nějakou novou featuru ohledně NCQ.
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í).

Každopádně to vše jsou opatření dočasná. Ty šindelové disky do toho pole nepatří, hrozí jim velmi časná smrt.

[RDa]

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

[ByCzech]

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

Různé schedulery řeší problémy s výkonem, ne se ztrátou dat.

[trubicoid2]

vypnutí NCQ vypíná i write-cache, jde to poznat z toho, že to bude pomale zapisovat

hdparm -W možná dokonce bude hlásit 1, teď nevím

podle mě je teda noncq stený jako hdparm -W 0, což fungovalo už předtím

[RDa]

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

Různé schedulery řeší problémy s výkonem, ne se ztrátou dat.

Ale zde je evidentni ze ztrata dat nastava bud podle zpusobu pouzivani, nebo podle objemu pouzivani. A oboji ti ten scheduler ovlivni (postaci kdyz jeden bude preferovat zapisy a druhy cteni..). Tim, ze na 1.5G to porad blbne, bych se klonil jen k vade pri specifickem zpusobu pouzivani disku.

[ByCzech]

vypnutí NCQ vypíná i write-cache, jde to poznat z toho, že to bude pomale zapisovat

hdparm -W možná dokonce bude hlásit 1, teď nevím

podle mě je teda noncq stený jako hdparm -W 0, což fungovalo už předtím

Nějaký zdroj k tomu? To by bylo zajímavé, kdyby to fungovalo takto...

[Petr Kratochvíl]

Závěr

Pokud nedošlo k chybě měření, tak pomáhá jedno z:

• Downgrade kernelu na 4.19.0
• Nechat vypnuté NCQ parametrem libata.force=noncq

Další postup

Která varianta je lepší, zůstat na 4.19.0 nebo vypnout NCQ?

Jak moc špatné by bylo mít trvale vypnuté NCQ?

Tipuji, že 4.19.0 bude lepší ohledně výkonu, než vypínat NCQ.

Ohledně výkonu asi lepší bude 4.19.0, ale kvůli používání Btrfs bych preferoval pravidelně aktualizovat kernel. Už nějakou dobu zvažuji přesunout mountování Btrfs do virtuálky (virtualbox, vmware, ...) a přistupovat k datům do virtuálky přes NFS a SSHFS. To by řešilo aktualizaci kernelu bez problému čtení a bez rebootu PC, jenže se obávám dopadu na výkon. Teď ještě trubicoid2 zmínil hdparm -W 0 místo vypnutí NCQ, tak ho také zahrnu jako variantu.

Kterou variantu zvolit?

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

Osobně jsem čekal, že z těch pokusů s kernelem zaberou přesně tyhle věci...

Dobrý odhad každý má, kdo to očekával.

Napadá vás nějaké lepší řešení, které by stálo za pokus?

Upgrade firmware.

Zadal jsem postupně s/n svých 4 disků Seagate Archive Exos 5E8 na webu výrobce:
https://apps1.seagate.com/downloads/request.html

Jedná se o následující s/n (kdyby někdo ze zvědavosti chtěl zkusit s odstupem času):
WCT0BQ83, WCT0BQ62, WCT0BKGX, WCT0C2EB.

Ve všech případech web ohledně firmware napsal:

• Name: "No Newer Firmware Available"
• Importance: -------
• Version: -------
• Release Date: 01-Dec-18
• Short Description: A field update is not available for this serial number. See if CERTIFICATE Firmware Update is shown below. Please help us to improve the Download Finder

Napadá vás jakými dalšími experimenty najít počáteční příčinu?

Osobně jsem si v podstatě z nových informací jist, že chyba je ve firmware některého z disků (nejspíše těch šindelových). Honbou za zlepšením výkonu mají nejspíše nějakou optimalizaci, která v běžném provozu funguje, ale ve složitější konfiguraci a s novějším kernelem naopak způsobuje bug (ve firmware), který vrátí v určitých případech za použití NCQ jiná data z cache, která si myslí, že jsou ta správná. Jiná verze kernelu to řeší nejspíše proto, že byl změněn algoritmus práce s NCQ. Možná by to stálo za prozkoumání.

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":
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.1

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

Každopádně řešení je jak jsem již psal dříve zkusit nahrát do disků nový firmware, je možné, že dost pravděpodobné, že chyba už v něm nebude, s velmi podobně chovající se věcí jsem se už setkal a firmware to řešil. A ano také to bylo v poli, se samostatným diskem se chyba neprojevila nikdy.

Zajímavá zkušenost.

Pokud se jedná o bug v kernelu, který by se mohl projevovat u dalších uživatelů, jsem ochotný i přes workaroundy výše nadále pátrat po příčině. Jen raďte, co mám dál zkusit.

Osobně si myslím, že to není bug, ale buď se změnila algoritmu při práci, která se projeví při zapnutém NCQ nebo kernel začal využívat nějakou novou featuru ohledně NCQ.

Souhlasím.

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

Každopádně to vše jsou opatření dočasná. Ty šindelové disky do toho pole nepatří, hrozí jim velmi časná smrt.

Už vymýšlím, jak to provést. 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)?

[trubicoid2]

• 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

odkaz na to nemám, ale si to zkuste, jak obě metody stejně sníží výkon při zápisu, pro ty šindeláře to musí být smrtelný

ncq jde vypnout a zapnout za chodu, když pošleš 1 nebo 31 do /sys/block/sdX/device/queue_depth

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

[JenTak]

Už vymýšlím, jak to provést. 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)?

Prosim vas, WD Red jsou disky do domacich krabicek typu Synology nebo Zyxel. 5400 otacek je malo, latence vhodna akorat tak pro BFU NAS. Vy mate RAID, na ktery paralelne pristupuje vice nejruznejsich procesu. Pokud se omezime na SATA magneticke disky, potrebujete 7200 otacek (nevim, ze by nekdo delal viceotackove disky jako SATA). Pokud priplatit, tak treba za WD Gold 8TB. Jinak je mozna i ten IronWolf lepsi nez WD Red. Obecne vyrobci (i prodejci) casto uvadi, zda je disk vhodny pro RAID. WD Gold mohu doporucit i z vlastni zkusenosti, ostatni nevim.

[JenTak]

A neni mi jasne, zda jste taky vyzkousel jiny zdroj. Ja bych to udelal. Odchazejici ci sesle zdroje umi opravdu vygenerovat nejroztodivnejsi chyby, ktere se tezko kategorizuji.