Příspěvky

316

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

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

317

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

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

To už není normální toto 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>

318

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

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

319

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

« kdy: 01. 12. 2018, 19:26:54 »

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

320

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

« kdy: 01. 12. 2018, 14:48: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

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

321

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

« kdy: 01. 12. 2018, 12:05:09 »

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.

322

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

« kdy: 30. 11. 2018, 15:34:10 »

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.

323

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

« kdy: 30. 11. 2018, 01:23:13 »

no a pokud se bude číst z raidu, to znamená synchronizovaně, bude efekt horší.

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.

324

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

« kdy: 29. 11. 2018, 22:34:14 »

Jasně ty disky berou okolo 5W (RED dokonce okolo 3,5W) ale budeme počítat 20 W.

tak vy si počítejte co chcete. nicméně při návrhu hw se vychází z mezních hodnot (jako třeba maximální odběr), nikoli ze středních hodnot.

update: argumentujete wd red. wd red podle datasheetu má v 4GB variantě jen na 12V lince špičkový odběr 1,75A. To dává nějakých 21W. viz https://cdn.cnetcontent.com/3a/07/3a07b8d6-7086-4c6f-80dd-ac1685c20336.pdf.

To má ten disk jen jednou - i s rezervou - při studeném startu, když roztáčí plotny a jen velmi krátce. 4 GB disk jsem už neviděl ani jako flashku v poslední době. Bylo by lepší, kdyby jste pohledali informace ze změřené spotřeby ne při chvilkovém proudovém rázu při startu a ke konkrétnímu modelu. Běžně má novější disk disk o větší kapacitě nižší spotřebu.

325

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

« kdy: 29. 11. 2018, 21:48:44 »

Prumerna spotreba je jedna vec, ale kdyz ty disky najednou zaberou, to se urcite nevejde pod soucet prumernych spotreb. Postupne spousteni disku pod HW radicem RAIDu se nedela jen tak z pleziru. Zdroj to musi ustat bez poklesu napeti.

Já bych doporučil určitě si to nastudovat...

326

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

« kdy: 29. 11. 2018, 20:39:47 »

Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

Výkonná grafická karta s odběrem okolo 40-50W? Jako vážně? To by tam těch disků muselo být několikanásobně více, výkonná grafická karta bere aspoň 200-300 W.

počítá se cca 20W/disk, což při těch 6 discích dává nějakých 120W.

Jasně ty disky berou okolo 5W (RED dokonce okolo 3,5W) ale budeme počítat 20 W.

327

Windows a jiné systémy / Re:Po instalaci Windows 7 nefunguje USB (klávesnice i myš) - ASRock

« kdy: 29. 11. 2018, 19:44:32 »

Vím, co dělám.

Ještě minulý týden jste tvrdil, že víte co děláte. Myslím si, že vůbec nevíte co děláte. Nejlepší rada, kterou můžete dostat je tato: Svěřte to někomu, kdo opravdu ví co dělá, protože tomu rozumí. A pokud by náhodou řekl, že Windows 7 jsou na tomto konkrétním HW neřešitelná věc, věřte mu. Řešením je pak jiná verze Windows, jiný OS nebo jiné PC.

328

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

« kdy: 29. 11. 2018, 18:41:29 »

Vypnu HPET v BIOSu (díky za tip)

HPET se dá vypnout i parametrem pro kernel hpet=disable, akorát nějak pořád nechápu čeho se tím má v souvislosti s popisovaným problémem docílit.

329

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

« kdy: 29. 11. 2018, 18:38:07 »

Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

Výkonná grafická karta s odběrem okolo 40-50W? Jako vážně? To by tam těch disků muselo být několikanásobně více, výkonná grafická karta bere aspoň 200-300 W.

330

Vývoj / Re:Free online správa překladů programu

« kdy: 29. 11. 2018, 14:40:39 »

https://poeditor.com/

To je FOSS?