Fórum Root.cz
Hlavní témata => Server => Téma založeno: Petr Kratochvíl 26. 11. 2018, 23:00:35
-
Ahoj všichni,
předem díky za jakoukoliv konstruktivní radu, došly mi nápady.
Úvod
Mám 7 disků, každý z nich 8 TB s jedním velkým oddílem /dev/sd[bcdijkl]1, vytvářející přes mdadm RAID 6 jedno blokové zařízení /dev/md0 velké 40007 GB. Na celém /dev/md0 jsou data šifrovaná přes dm-crypt/LUKS, na kterém je LVM a na něm cca 20 oddílů ext4 a Btrfs, ale to je teď vedlejší, protože problém nastává již před připojením šifrovaného oddílu, tj. před provedením cryptsetup luksOpen /dev/md0 <dm_name>.
Stručný popis
Občas se čtou z mdadm RAID 6 pole /dev/md0 náhodná data, při současném zápisu se čtou velmi často náhodná data. Čtení z jednotlivých disků čte vždy stejná data, nikdy náhodná. Dle mdadm check je pole v pořádku.
Experiment č. 1: čtení z /dev/md0
Pokud zkusím číst opakovaně stejných 10 GiB z /dev/md0 od offsetu 1 TiB, mají data dle očekávání vždy stejný md5 checksum:
root@krato-space:~# for DEV in md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..6} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum )
; done ) ; done ; date
==== md0 ====
Po lis 26 12:13:26 CET 2018
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
Po lis 26 12:16:03 CET 2018
Experiment č. 2: čtení z /dev/md0
Občas je oproti očekávání ne vždy stejný md5 checksum (viz poslední):
root@krato-space:~# for DEV in md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..4} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum ) ; done ) ; done ; date
==== md0 ====
Po lis 26 22:20:25 CET 2018
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
03247245c2a9920f6acc2ce7ce51ad92 -
1e434d76b388b0c21dec709a6d1b6d20 -
Po lis 26 22:22:08 CET 2018
Experiment č. 3: čtení z /dev/md0 při zápisu
A teď pozor. Pokud při čtení zároveň probíhá jakýkoliv zápis na jiném místě pole, přečtu z /dev/md0 občas nebo pokaždé data s jiným checksumem.
Říkám si, že mi leží těch 7 SATA kabelů volně uvnitř i vně case (disky leží vedle case, dovnitř se už nevešly), tak zda nechytají nějaké rušení nebo nezlobí některý ze dvou SATA řadičů, jenže pokud čtu data z disků zvlášť, je checksum vždy v pořádku. První a poslední čtveřice jsou checksumy 10 GiB čtených z /dev/md0, sedm čtveřic mezi nimi jsou čtení z jednotlivých disků:
root@krato-space:~# for DEV in md0 sdb1 sdc1 sdd1 sdi1 sdj1 sdk1 sdl1 md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..4} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum ) ; done ) ; done ; date
==== md0 ====
Po lis 26 20:03:03 CET 2018
31a877f49150e0f6452b843d81a8c88d -
9b2010d3fb1344139f9eba21ad309b7b -
e11e03afc313e5de46105f15ffc33665 -
9bfde541773fc0ef03a4b1ff1c45621c -
==== sdb1 ====
Po lis 26 20:08:15 CET 2018
7fdc1658562a2ecd4d676bf656c973a7 -
7fdc1658562a2ecd4d676bf656c973a7 -
7fdc1658562a2ecd4d676bf656c973a7 -
7fdc1658562a2ecd4d676bf656c973a7 -
==== sdc1 ====
Po lis 26 20:26:35 CET 2018
7c671e9e47fdb2604e2ecfcea6009218 -
7c671e9e47fdb2604e2ecfcea6009218 -
7c671e9e47fdb2604e2ecfcea6009218 -
7c671e9e47fdb2604e2ecfcea6009218 -
==== sdd1 ====
Po lis 26 20:45:38 CET 2018
bb14e932be6c2ae2751404a997c24712 -
bb14e932be6c2ae2751404a997c24712 -
bb14e932be6c2ae2751404a997c24712 -
bb14e932be6c2ae2751404a997c24712 -
==== sdi1 ====
Po lis 26 20:56:27 CET 2018
4fb8ad4d063fff30e39ff64205713952 -
4fb8ad4d063fff30e39ff64205713952 -
4fb8ad4d063fff30e39ff64205713952 -
4fb8ad4d063fff30e39ff64205713952 -
==== sdj1 ====
Po lis 26 21:07:44 CET 2018
00528ce93f8c54882d022f976004442f -
00528ce93f8c54882d022f976004442f -
00528ce93f8c54882d022f976004442f -
00528ce93f8c54882d022f976004442f -
==== sdk1 ====
Po lis 26 21:38:04 CET 2018
33d73ace82b8bc28fd284fc32c216039 -
33d73ace82b8bc28fd284fc32c216039 -
33d73ace82b8bc28fd284fc32c216039 -
33d73ace82b8bc28fd284fc32c216039 -
==== sdl1 ====
Po lis 26 21:45:57 CET 2018
842b476f2973e16403f3fc1a031b968a -
842b476f2973e16403f3fc1a031b968a -
842b476f2973e16403f3fc1a031b968a -
842b476f2973e16403f3fc1a031b968a -
==== md0 ====
Po lis 26 21:53:30 CET 2018
e08baf910b005f1f001c8258330a0637 -
4ce735569e51ad0e75d4775a0a2e565b -
d740da3b4b7a2167ca369c9b00efe6d2 -
75f0c751bbd8f95b0ed6d49c379f9ff8 -
Po lis 26 22:06:22 CET 2018
Konkrétně u tohoto experimentu č. 3 jsem prováděl zápis tím způsobem, že jsem na jiném offsetu 1 GiB načetl 100 GiB dat do souboru na systémovém SSD disku:
dd if=/dev/md0 bs=1M count=102400 skip=1024 status=progress of=/root/md0_offset-1024M_size-102400M-2018-11-26-1308.bin
A tato data jsem pak při testu čtení v cyklu zapisoval zpět přesně tam, odkud jsem je přečetl:
for i in {1..10} ; do dd if=/root/md0_offset-1024M_size-102400M-2018-11-26-1308.bin bs=1M count=102400 seek=1024 status=progress of=/dev/md0 ; done
Chyba software vs. hardware
Nezkouším koupit nový hardware (kabely, case, zdroj, disky, ...), protože při čtení z jednotlivých disků zvlášť nikdy tento problém nepozoruji.
Vyloučení nekonzistence dat RAID 6
Už se určitě chystáte poradit mdadm check a mdadm resync. To by to ale bylo příliš jednoduché.
Před testy výše jsem provedl postupně:
- mdadm resync ... našel 3688 chyb (dle čísla v /sys/block/md0/md/mismatch_cnt)
- mdadm check ... našel 0 chyb (dle čísla v /sys/block/md0/md/mismatch_cnt)
Verze software
root@krato-space:~# lsb_release --description
Description: Ubuntu 18.04.1 LTS
root@krato-space:~# uname --all
Linux krato-space 4.19.2-041902-generic #201811132032 SMP Tue Nov 13 20:34:19 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@krato-space:~# mdadm --version
mdadm - v4.1-rc1 - 2018-03-22
-
Vypni cache jednotlivych disku, vykon ti teda dost padne, ale aspon na test to zkus.
-
Cteni 10GB z /dev/sdX+1GB neodpovida lokaci ktera je z tech sestavenych disku do /dev/mdX+1GB
A pokud pises "provadi se zapis na jine misto", tak v pripade ze mas nad tim LVM, je zcela mozne ze ty bloky se ti prekryvaj a meni se ti /dev/mdX prave tam kde to necekas.
-
Vypni cache jednotlivych disku, vykon ti teda dost padne, ale aspon na test to zkus.
Díky za tip!
Klobouk dolů, to by mě nenapadlo.
Cache disků jsem vypnul takto příkazem hdparm v cyklu:
for DEV in sdb1 sdc1 sdd1 sdi1 sdj1 sdk1 sdl1 ; do hdparm -W 0 /dev/$DEV ; done
A zkusil znova testy čtení při zápisu (20x čtení stejných 10 GiB při kontinuálním zápisu na jiný offset). Testy postupně dopadly:
- Vypnutí diskových cache.
- Čtení při zápisu: OK
- Zapnutí diskových cache.
- Čtení při zápisu: náhodná data
- Vypnutí diskových cache.
- Čtení při zápisu: OK
Pro info: čtení při zápisu je vypnutou cache cca 5x pomalejší, s čímž počítáme.
Prosím, jaká je tedy prvotní příčina a jak postupovat dál?
-
Cteni 10GB z /dev/sdX+1GB neodpovida lokaci ktera je z tech sestavenych disku do /dev/mdX+1GB
To je pravda. Šlo mi hlavně o čtení z jiného místa než kam se zapisuje. Jiné testy ukázaly, že asi vůbec nezáleží na offsetu, problém se projevil stejně i při jiných offsetech.
A pokud pises "provadi se zapis na jine misto", tak v pripade ze mas nad tim LVM, je zcela mozne ze ty bloky se ti prekryvaj a meni se ti /dev/mdX prave tam kde to necekas.
Chápu přesně pointu, ale LVM mám na šifrovaném oddílu, který není připojený. Tj. nepoužil jsem cryptsetup luksOpen a problém se přesto projevuje. Pro jistotu uvedu vrstvy jak leží na sobě (jsem otevřen radám na vylepšení):
- fyzicky 7 disků 8 TB
- na každém disku partitiona přes celý disk /dev/sdX1
- mdadm RAID 6 přes všech 7 partitions (vytváří 40 TB blokové zařízení /dev/md0)
- dm-crypt/LUKS
- LVM Physical Device
- LVM Volume Group (sestává se jen z /dev/md0)
- LVM Logical Volumes
- ext4 a Btrfs na LVM logických oddílech (některé r, některé rw; některé snapshoty)
- Btrfs oddíly mají vždy 1 nebo více subvolumes (když už dělíme do vrstev)
Problém se projevuje před zadáním hesla, tj. na prvních 3 vrstvách:
- fyzicky 7 disků 8 TB
- na každém disku partitiona přes celý disk /dev/sdX1
- mdadm RAID 6 přes všech 7 partitions (vytváří 40 TB blokové zařízení /dev/md0)
-
Jako chova se ti to hodne divne.
Zkus namisto cteni pouzit kopirovani (do RAM - /dev/shm) a nad tim md5, pokud je stejny jako predesla kopie tak se udela cteni znova. Jen musis mit v ram dve kopie stejneho regionu. Az ti to zahlasi ze md5 nesouhlasi, tak ty dva soubory porovnas.. a zjistis co se s tim vlastne stalo - bud se zmeni 1 bit, nejaky sektor, nebo cely raid stripe.
Tip pro porovnani dvou X GB souboru: udelej si skript co projede pres 1M bloky md5 a pak diff tech dvou seznamu md5. Vadnej chunk pak extrahuj, hexdump -Cv a pak diff 1.hex 2.hex (takto jsem nasel 1 flipnuty bit v 18G instalacce).
-
Co rika opakovany mdadm resync? Jake jsou to disky a jaky je to radic?
-
Chmm ... prejit na nejakej HW raid. Totiz tohle vypada na nejakej hlubsi problem v tom SW raidu, s tim tezko neco nejak rychle udelas. Podle me se to bude projevovat prave jen kdyz mas vic disku, takze mnoztvi lidi ktery by to byly schopny testovat nebude velky a navic to muze souviset i s chovanim konkretnich disku. Rek bych ze to bude neco na tema potvrzovani transakci/invalidace cache/...
Pripadne jeste muzes testnout jiny verze kernelu.
-
Vadná ram nebo chyba v software.
Řešení?
Nechovat se jako pako a požít Arecu ::)
-
IMO je nejjednodušší řešení přejít u takhle velkého pole na ZFS (+ samozřejmě ECC paměti).
-
:)
-
Cache disků jsem vypnul takto příkazem hdparm v cyklu:
...
Pro info: čtení při zápisu je vypnutou cache cca 5x pomalejší, s čímž počítáme.
Prosím, jaká je tedy prvotní příčina a jak postupovat dál?
Co to jsou přesně za disky? Fungovalo to dříve, nebo to je nové pole?
-
Vadná ram nebo chyba v software.
Jasně a vadnou ram nebo chybu v software vyřeší vypnutí HW cache na disku :D
-
Hledal bych prvotní příčinu v těch dvou SATA řadičích, nemusí si rozumět s ovladači pokus mají probíhat operace současně na obou.
-
Jako chova se ti to hodne divne.
Zkus namisto cteni pouzit kopirovani (do RAM - /dev/shm) a nad tim md5, pokud je stejny jako predesla kopie tak se udela cteni znova. Jen musis mit v ram dve kopie stejneho regionu. Az ti to zahlasi ze md5 nesouhlasi, tak ty dva soubory porovnas.. a zjistis co se s tim vlastne stalo - bud se zmeni 1 bit, nejaky sektor, nebo cely raid stripe.
Tip pro porovnani dvou X GB souboru: udelej si skript co projede pres 1M bloky md5 a pak diff tech dvou seznamu md5. Vadnej chunk pak extrahuj, hexdump -Cv a pak diff 1.hex 2.hex (takto jsem nasel 1 flipnuty bit v 18G instalacce).
Díky za tip a donucení k testu, který na konec nebylo zas tak složité vytvořit. Výsledek prozatím jednoho nalezení rozdílu:
Rozdíl ve dvou po sobě jdoucích načteních je na offsetu 830,5 MiB a je dlouhý přesně 160 KiB (liší se celý tento blok). Když vydělíme velikost rozdílu číslem 5 (protože je 7 disků z RAIDu 6 => 7-2=5), vyjde nám hezké IT-kulaté číslo:
160 KiB / 5 = 32 KiB
Což může, ale nemusí být náhoda.
Podle příkazu mdadm -E /dev/sdb1 | grep "Chunk Size" je mdadm chunk size na mdadm disku: 256 KiB
Co z toho vyplývá?
O víkendu mohu zkusit downgrade kernelu (což bych už jen kvůli Btrfs nerad natrvalo).
-
Co to jsou přesně za disky?
Disky to jsou běžně dostupné mechanické všechny 8 TB, konkrétně tyto:
- 4x Seagate Archive Exos 5E8
- 1x Seagate IronWolf 8TB
- 2x Western Digital WD Red 8TB
Co to jsou přesně za disky? Fungovalo to dříve, nebo to je nové pole?
Pole je staré cca 6 měsíců (stejných 7 disků) a tyto problémy pozoruji cca 2 měsíce.
Dříve (před cca 5 měsíci) jsem na pole nakopíroval 8 TB z jiného disku, porovnal md5 checksum na původním disku a na poli a checksumy odpovídaly. A to jsem při zápisu a porovnávání normálně pole používal read-write na jiná data (zálohy serverů, ...).
Asi bych o víkendu zkusil downgrade na nějaký tak 6 měsíců starý kernel. Ale jestli problém bude stále, tak nevím. A jestli nebude, tak také nevím, zda pak zůstat na starém kernelu nebo jak najít příčinu (v changelogs a commitech kernelu?).
Může nás někam dovést ta souvislost problému s cache v disku?
Navíc mě trochu děsí, že pokud je příčina někde mezi disk-cache, řadič a kernelem, tak se totéž teoreticky může stát každému běžnému uživateli s jedním diskem. Akorát se o tom ani nedozví, pokud nepoužívá FS s checksumy dat (Btrfs, ZFS, ...).
-
Jak moc je to pole plné? Výhodou ZFS je například synchronizace (resilvering) pouze obsazeného prostoru, narozdíl od mdadm. Tam resync 8TB disku na raid6 může být na hodně dlouho....
-
Jak moc je to pole plné? Výhodou ZFS je například synchronizace (resilvering) pouze obsazeného prostoru, narozdíl od mdadm. Tam resync 8TB disku na raid6 může být na hodně dlouho....
Obsazeno cca 37 z 40 TB a do budoucna se počítá s podobným obsazením pole.
Navíc pro výběr Btrfs místo ZFS jsem měl po 2 letech vybírání a testování argumenty, které by ani elegantní resilvering nepřevážil.
-
No, btrfs s raid6 na 40TB, to přeji hodně štěstí :-)
-
Co to jsou přesně za disky?
Disky to jsou běžně dostupné mechanické všechny 8 TB, konkrétně tyto:
- 4x Seagate Archive Exos 5E8
- 1x Seagate IronWolf 8TB
- 2x Western Digital WD Red 8TB
No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".
-
Jako první bych kouknul, jestli mají ty disky v pořádku napájení a jestli se nepřehřívají. Dokud není ok tohle, diagnostika ostatních věcí může vést k nesmyslným závěrům. A to stejné pro řadiče.
-
No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".
Takže jsem špatně Googlil a omylem koupil zase šindele. To už se mi stalo kdysi se Seagate Archive a dodnes mám na něj špatné vzpomínky korenspondující s tímto krásným článkem o šindelovém zápisu (SMR):
https://diit.cz/clanek/recenze-8tb-seagate-archive
Moje zkušenosti se SMR tenkrát odpovídaly přesně názvu 3. kapitoly, tj. "Zahlcení disku do bezvědomí".
Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.
Na aktualizaci firmware se o víkendu podívám. Super by bylo, kdyby pomohla.
-
Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.
Teoreticky ano, jenže tyhle disky běžně lžou např. o tom, že data jsou komplet zapsána tam kde by měla být a jsou děsně překombinované samy o sobě a když se k tomu přidá NCQ, cache,... tak tohle se prostě při složitější konfiguraci (RAID) s nimi stává, že dělají co nemají a jedinou nadějí je nový firmware, který ty mezní stavy, které vznikají až v diskových polích ošetří, protože jednotlivé disky jsou obvykle OK, přestože se jak píšete dají lehce uštvat na random access. Navíc novější jednotky zdá se používají finty, kdy první zápisy jsou bez šindelů a až když se vyčerpá většina téhle klasické kapacity, začnou přerovnávat do šindelů a je zle, k tomu se přidá to, že firmware disku lže o kompletním zapsání dat ap. a problém je při souběhu specifického čtení/zápis na světě.
-
SMR disky bych fakt vyndal, sám je používám, ale prostě jen osamocené nebo RAID1 jsou naprosto nevhodné do tohoto provozu.
Pokud se zápis nefragmentuje, zapíšou celkem rychle hodně dat, ale to v kombinaci se žurnálem není příliš častý jev.
Jsou vhodné asi jen na speciální použití a do datacenter popř. jako samostatný disk.
Ztrátu dat jsem ale nikdy neviděl. Nicméně pokud jsou tam čtyři a náhodně se odpojujou po překročení té neSMR oblasti, tak se můžou dít věci nečekané.
-
Skuste sa pohrat s nasledujucimi moznostami.
1. Vypnite HPET v BIOSe
2. Vyskusajte nasledujuce parametre kernelu.
libata.force=noncq
libata.force=1.5
libata.force=3.0
-
Ti asi mrdá, ne, narvat si do RAIDu SMRTky... ::) ??? :o
-
No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".
Takže jsem špatně Googlil a omylem koupil zase šindele. To už se mi stalo kdysi se Seagate Archive a dodnes mám na něj špatné vzpomínky korenspondující s tímto krásným článkem o šindelovém zápisu (SMR):
https://diit.cz/clanek/recenze-8tb-seagate-archive
Moje zkušenosti se SMR tenkrát odpovídaly přesně názvu 3. kapitoly, tj. "Zahlcení disku do bezvědomí".
Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.
Na aktualizaci firmware se o víkendu podívám. Super by bylo, kdyby pomohla.
https://www.seagate.com/www-content/datasheets/pdfs/exos-5e8DS1954-1-1709US-en_US.pdf
jsou smr, drive managed, tudiz jsi koupil blbe. Kombinace tech disku a raidu muze generovat nekonzistentni data.
-
Tak snad ještě praktickou poznámku...
Takže jsem špatně Googlil a omylem koupil zase šindele.
Vzhledem ke kvalitě dokumentace a ochotě výrobců přiznávat použití SMRtící technologie do jakékoliv objednávky disků automaticky do poznámky píšu (optimálně se zapnutým Caps Lockem): NESMÍ SE JEDNAT O SMR DISK!!!
V případě, že zjistím, že je to SMRtka, automaticky reklamuju s odkazem na objednávku. Vyřízeno, vyřešeno.
-
Kluci, ale zadny drive-managed SMR disk uz z principu nemuze produkovat nekonzistentni data, cache, ne-cache!
Kde mate dukaz ze tyhle disky nectou to, co jste do nich zapsali??
To, jak se tyto SMR interne chovaji odpovida modernim SSD se SLC cache (zapis jede do docasneho uloziste, po jehoz zaplneni rychlost znatelne poklesne - coz muze disk vyhodit z raid-pole u hw radice z duvodu ze nereaguje). Na pozadi se to pak vklada do bloku ktere lze prepisovat jen jednim smerem.
Ten 160 KiB blok je podle me spis jen v ramci jednoho stripe (podle presneho offsetu to muzes rict zda jo nebo ne). Delit poctem disku to nema tady smysl. Kdyby to nebyly dulezite data, tak bych rad videl co se to tam zmenilo a jak (klidne PM).
Pokud chces dal experimentovat, tak cti jak /dev/mdX tak /dev/sdX ze stejnych mist (resp. mel bys byt schopen spocitat kde se onen 160kB blok nachazi). V pripade, ze se zmeni data na 3 discich zaroven, tak to je regulerni zapis (coz spis neni, kdyz kontrola konzistence pole ti vraci errory). Takze to spis muze byt vadnej port/kabel na jednom disku (pokud ten offset bude pri dalsich chybach indikovat ze to je puvodem z jednoho disku). Nez experiment s jinou verzi kernelu bych zvazil experiment se znatelne jinym hw (intel^amd) a ponechat jen disky, vymenit i kabely.
-
a ponechat jen disky
Ano, ponechat disky, které jsou v RAIDu naprosto neprovozovatelné a vyhodit vše ostatní, to dává skutečně smysl. ;D ::)
-
možná koukni na stabilitu napětí, zápis a čtení na 6 disků zároveň žere víc, než když testuješ jen po jednom disku postupně
zdroj to neudrží, napětí poklesne a máš blbosti
vyloučit to můžeš čtením z jednoho disku zatímco na všechny budeš třeba zapisovat, nebo dokonce zapisovat a číst, seek má asi největší spotřebu
-
a ponechat jen disky
Ano, ponechat disky, které jsou v RAIDu naprosto neprovozovatelné a vyhodit vše ostatní, to dává skutečně smysl. ;D ::)
Pokud ma vadnej kabel, zdroj, pameti, cpu, tak mu sebelepsi disk nepomuze. Pokud sis nevsim, porad se hleda zavada. Vypnuti cache na disku jenom snizi pocet operaci a pravdepodobnost chyby klesne, ale neni to reseni ani duvod chyby. To by taky rovnou mohl zkusit jet na 1.5G - SATA gen I, nebo zkrouhnout traffic, aby se to "ustihalo". Taky to ale neni reseni!
-
Kluci, ale zadny drive-managed SMR disk uz z principu nemuze produkovat nekonzistentni data, cache, ne-cache!
Z principu ne, z praxe ano. já viděl už takové hromady vadných zařízení, že to ani nespočítám, takže tvrdit mi, že něco nemůže produkovat problémy je pro mě mimo realitu.
-
No, btrfs s raid6 na 40TB, to přeji hodně štěstí :-)
Jestli to nebude tim, ze ty netusis o cem pises, on nepouziva BRTFS RAID. Kdyby pouzival, nejspis by to fungovalo, protoze se to chova jinak.
....
Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.
Nemelo, ale jestlize to sou tyhle hruzy, tak je mozny ze tam dojde prave predevsim tim zapisem ke vzniku nejakych nechutnych latenci ... hlavne bych se teda bal ty kombinace ruznych disku, kdy jeden odpovi klidne 100x driv nez jinej.
A viz vejs, kdybys tam nemel ten mdraid, ale btrfs raid, nejspis bys na to nenarazil, protoze by to snima pracovalo jako s jednotlivejma diskama. Rizika musis zvazit sam.
-
Ahojte,
nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS). Jestli sem pochopil tak ctete data v nejakem nahodne rozmezi a vlastne netusite co za data na tom miste je. Dokau si pradstavit ze v tom 1TB bloku co ctete sou umistena metadata treba toho dm-crypt ktera se necim meni (timestamp, velikosti, etc...) a je uplne jedno jestli pisete do lokace 1TB, 3TB nebo 7TB. dm-crypt je aktivni nad celym 7TB svazkem a co tam presne dm-crypt dela zjistite az budete dokonale znat zdrojovy kod...
Osobne bych cely tenhle clanek prejmenoval, neco mi prepisuje data v dm-crypt kontejneru na jinem miste nez bych cekal. Urcite tohle nepovazuju za chybu cteni dokudk nedokazete ze mate nekonzistentni soubory....
Psal ste ze jsem porovnaval md5 zkopirovanych souboru behem migradce na tohle pole. Ma nejaky soubor ktery se od te doby nezmenil jine md5 nez behem migrace?
-
nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS).
Jestli to chápu správně já, tak řeší pouze md0 (z napsaného předpokládám, že LVM a dm-crypt jsou v tu dobu neaktivní, protože číst blok dat ze zařízení, na kterém probíhají jiné operace výš by bylo opravdu úplně špatně a to samé si můžeme nasimulovat s jedním diskem, čtením z oddílu, když máme připojen souborový systém na tomto oddílu a něco s daty na FS pracuje) a z toho co tu píše, opakovaně čte blok dat ze zařízení /dev/md0. Občas při čtení toho stejného bloku dat to vyhodí jiný checksum = přečetla se jiná data.
Zhorší se to o to víc, když předem vyčtený (jiný) blok dat z /dev/md0 zapisuje zpět na stejné místo a opakuje test se čtením původního bloku dat. Data jsou častěji vyčtena jinak.
Nějak se mi nechce věřit, že by někdo byl takový hazardér a hrál si s blokovým zařízením výše popsaným způsobem, když by byly aktivní další vyšší vrstvy (LVM, dm-crypt, FS). Osobně předpokládám, že aktivní nejsou...
-
nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS).
Jestli to chápu správně já, tak řeší pouze md0 (z napsaného předpokládám, že LVM a dm-crypt jsou v tu dobu neaktivní, protože číst blok dat ze zařízení, na kterém probíhají jiné operace výš by bylo opravdu úplně špatně a to samé si můžeme nasimulovat s jedním diskem, čtením z oddílu, když máme připojen souborový systém na tomto oddílu a něco s daty na FS pracuje) a z toho co tu píše, opakovaně čte blok dat ze zařízení /dev/md0. Občas při čtení toho stejného bloku dat to vyhodí jiný checksum = přečetla se jiná data.
Naprosto správně. Zapisuji (resp. čtu) pouze přímo na blokové zařízení /dev/md0, ne do souboru.
Nějak se mi nechce věřit, že by někdo byl takový hazardér a hrál si s blokovým zařízením výše popsaným způsobem, když by byly aktivní další vyšší vrstvy (LVM, dm-crypt, FS). Osobně předpokládám, že aktivní nejsou...
Správný předpoklad. Jak jsem psal, problém nastává už před zadáním cryptsetup luksOpen. tj. při testu nebyly aktivní vrstvy dm-crypt, LVM, ... Na ty se odvážím až si /dev/md0 získá zpátky důvěru.
-
A viz vejs, kdybys tam nemel ten mdraid, ale btrfs raid, nejspis bys na to nenarazil, protoze by to snima pracovalo jako s jednotlivejma diskama. Rizika musis zvazit sam.
Opět zajímavá myšlenka. Díky i za předchozí rady.
Historie pole
Měl bych popsat historii toho pole /dev/md0. Měsíce jsou plus mínus 1 měsíc, jde hlavně o chronologii. Sry, stručněji to sepsat neumím.
- 2018 květen ... nákup 7 disků do PC s aktuálním Xubuntu, všechny prošly napoprvé plným badblocks testem. Vytvořeno md0, na něj umístěna vrstva dm-crypt/LUKS a přímo na ni jedno velké Btrfs (po starších zkušenostech jsem měl v Btrfs 100% důvěru). Od této chvíle pravidelně instalovány poslední stabilní verze kernelu (přes ukuu).
- 2018 červen - červenec ... naplnění daty = desítky milionů souborů, několik subvolumes (vč. snapshotů) a několik velkých souborů s bitovými kopiemi oddílů jiných disků (8 TB, 3 TB, 2 TB, ...).
- 2018 srpen ... ověření dat zkopírovaných z jiných disků (rsync -c na soubory a md5sum na image oddílů) ... všechny MD5 checksumy perfektně odpovídají, včetně checksumu 8 TB souboru (obsahujícího Btrfs oddíl ze staršího 8 TB disku). Vše funguje perfektně.
- 2018 září ... naimportovány tisíce subvolumes přes btrfs receive rozdílových streamů (current vs. parent subvolume), zadáno smazání několika velkých subvolume, btrfs receive dvou možná vadných streamů...
- 2018 září ... zděšení ... některé adresáře jsou nečitelné, u některých souborů nesedí checksum dat => 40 TB Btrfs volume is corrupted
- 2018 září ... přechod z Btrfs na LVM s cca dvaceti Btrfs oddílů (cenná data na read-only oddílech, nastaveno přes LVM: "lvchange -pr") a znova plnění z disků, které jsem ještě nesmazal
- 2018 říjen ... zděšení ... u některých oddílů checksum sedí, u některých ne
- 2018 listopad ... 1 ze 7 disků vykopnut z pole, hází chyby čtení, po restartu PC funguje normálně a nevykazuje sebemenší problém, vrátil jsem ho do pole
- 2018 listopad ... pole read-only (při testech zapisuji data na místa, odkud jsem je přečetl a nic jiného by zapisovat nemělo), snažím se najít příčinu
Moje hypotézy
- zhroucení FS v září ... nějaký Btrfs bug (nebo nedostatečná blbuvzdornost btrfs receive)? Měl jsem cca 100 milionů unikátních souborů, 2800 snapshotů, několik souborů nad 1 TB, denně jsem importoval cca 200 rozdílových btrfs streamů (inkr. zálohování btrfs send-receive), při tom jsem zadal smazání několika snapshotů velkých několik TB a naimportoval (btrfs receive) dva Btrfs streamy, ve kterých jsem se ručně povrtal (změnil parent uuid)
- vykopnutí disku v listopadu ... mohl to být následek, že se přečetla špatně nějaká důležitá data?
- chyby čtení při zápisu ... myslím si, že se změnil ovladač SATA řadiče nebo mdadm v nějaké cca říjnové verzi kernelu
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
- Otestuji, zda z toho lze alespoň vytáhnout data při vypnutých diskových cache. Buď to holt tak používat (btrfs by hodilo chybu kdyby se něco přečetlo špatně, neboť při čtení kontroluje checksumy dat, když se to nevypne) nebo našetřit na nové stejné pole a na něm to zkusit znova (a 2 pole pak mít na různých místech a používat jedno jako zálohu druhého)
-
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.
-
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.
-
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.
-
Docela se začínám bavit... Kup si 8 obřích disků, z nichž 5 se naprosto nehodí do RAIDu, nad to nahoď šifrování, a navrch přihoď filesystém, u kterého je notoricky známo, že když se posere, tak jsou data vyřízená, mnoha a doplň to o pár tisíc subvolumes a pár desítek milionů souborů. Hele, jestli se chceš zbavit přebytečných dat, tak je prostě normálně smaž, není potřeba trávit mládí s podobnými nesmyslnými experimenty.
Jinak až tě to omrzí, tak bych doporučil pořídit normální disky a nahodit třeba FreeBSD a ZFS RAID-Z2.
-
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.
ten vývoj v čase, co OP popisuje, se dá vysvětlit klidně i odcházejícíma kondenzátorama na výstupu zdroje.
-
- 2018 listopad ... 1 ze 7 disků vykopnut z pole, hází chyby čtení, po restartu PC funguje normálně a nevykazuje sebemenší problém, vrátil jsem ho do pole
Najdi si duvod v syslogu - a podivej se, co se delo pred tim nez to mdraid vyhodil. Typicky je tam treba neco se SATA (coz muze byt napr. to chovani od SMR, ze to bude mit silene latence a jednou ten pohar trpelivosti sw raidu pretece).
Opravdu to nemuzes zkusit na jinem HW? To je totiz prvni co by se melo udelat, nez se trapit s potencialne vadnym hw. Ono totiz kdyby byl bug v sw/driveru, tak by se to tykalo vsech, tim ze se problem tyka jen tebe, tak to muze byt hw error.
Napajeni - doufam ze nemas 6 disku na jednom kabelu od zdroje, ale mas to vybalancovany po dvou, max trech. To same mechanicky - neRAID disky nemaji uplne rady vibrace, ktere delaj sousedni disky, takze bys to mel mit idealne rozlozeno od sebe a v ruznych uhlech. Vliv vibraci krasne ilustruje jedno video s nazvem ve stylu "do not shout on your disk array"
Ohledne zmeneneho 160kB bloku - zmena je pak trvala? Jaky je charakter dalsich chyb? (stejne misto, nebo ruzne misto? Lze identifikovat data, ktera tam jsou? (jestli udelas md5 pro kazdy 4kB blok, tak bys dokazal rict, odkud se tyto data vzali), pro rychle overeni staci treba "strings" pokud by to byl blok normalnich dat (coz asi nebude jestli mas ty data od dmcrypt).
-
Jinak až tě to omrzí, tak bych doporučil pořídit normální disky a nahodit třeba FreeBSD a ZFS RAID-Z2.
Chci videt jak spolehlive bude ZFS nad nespolehlivym diskem (vadnym kabelem), obzvlast v pripade, kdy takove zkriplene uloziste bude pouzivano pro slog :)
-
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.
-
Jasně ty disky berou okolo 5W (RED dokonce okolo 3,5W) ale budeme počítat 20 W.
Já bych pro jistotu počítal 50W. Myslím, že na takový velkostroj s 8 disky bude 1500W zdroj minimum. No, a já si jdu mezitím pohrát se svým perpetuum mobile od Dellu, co s Xeonem E3-1270 v6, 32GB RAM a 4x4TB SAS disky žere 54W. :o ::) ;D
-
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.
-
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.
-
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...
-
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.
(https://www.pcper.com/files/review/2016-03-21/power.png)
-
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.
Ok, v následujících dnech zkusím zjistit (nejsem teď u toho stroje).
Ohledně hardware
Zatím jsem ho příliš nepopisoval, protože se stejným hardware přes léto (červen až srpen) fungovalo vše perfektně.
Ukládal jsem na pole 8 TB dat do jednoho souboru na Btrfs a zároveň probíhalo spoustu jiných činností, např. CrashPlan si min. jednou prošel cca milion adresářů na celém poli, probíhalo v každé hodině ukládání záloh, počítání md5 checksum nějakých dat atd., podotýkám, že Btrfs při čtení kontroluje checksumy dat (nevypínal jsem ho), takže při prvním problému by některá z aplikací zobrazila chybu. Ale to se nestalo. Samozřejmě to nevylučuje, že mohlo nějaké hardware začít nenápadně zlobit a nebo příp. že něco přehlížím (častý jev uživatele popisujícího změny hw+sw za určité období).
-
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.
já hledal ten disk podle názvu, nedal jste přesnější údaje. ;) no ale to je jedno.. zrovna tenhle údaj nejde moc vylepšit, dokud jsou ty plotny stejně těžké a disk má stejné otáčky. pokud by to chtěli vylepšit, musel by se roztáčet opravdu dlouho (což by zas dělalo problémy s probouzením disku atd..)
pro výběr zdroje je důležitý údaj o špičkovém proudu z datasheetu nebo aspoň změřený při rozeběhu. zdroj musí všechno utáhnout i když se disky roztáčí současně. pokud utáhne všechno při startu, má i rezervy na různé špičky v odběru během normálního provozu. ten střední odběr, co ukazujete na grafech, moc neříká nic o špičkách, které vznikají během provozu (a s kterýma se zdroj musí vypořádávat, na 12V lince je povolená tolerance 10%, z které pokud se i během špičky odběru vyleze, není chování periferií na 12V lince definované)
mě je samozřejmě jasné, že během normálního provozu je ten střední odběr několikrát nižší. takže když chce někdo ušetřit za zdroj, tak si nastaví v biosu, aby se disky roztáčely postupně. což je ale jenom takovej trik. stejně zdroj musí mít vevnitř dost velké kondenzátory, aby kompenzoval špičky během běžného provozu. ale dostatečně velké kondenzátory mívají právě až ty výkonnější a kvalitnější zdroje. výrobci šetří na kondenzátorech. a někdy to dělají i výrobci serverového hw - potkal jsem třeba redundantní serverové zdroje, co počítaly s kapacitou kondenzátorů toho druhého redundantního zdroje a když tam nebyl, tak se ty kondíky během asi půl roku opotřebovaly a server začal dělat blbosti.
-
(https://www.pcper.com/files/review/2016-03-21/power.png)
koukám ještě na ten graf a přece jen se z něj dá něco vyčíst i o špičkách za běžného provozu. protože je tam vidět rozdíl mezi náhodným a sekvenčním čtením, což je rozdíl v energii, který imo padne z významné části na pohyby hlavičky. v grafu vidím rozdíly cca 0,5-2W a bude tam peak odpovídající době, kdy se hlavička pohybuje (to může být tak 10% z čtecího cyklu, záleží).
no a pokud se bude číst z raidu, to znamená synchronizovaně, bude efekt horší.
-
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.
-
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.
-
Raději pořídím zdroj 3000W, kdyby byl efekt úplně nejhorší... ;D ::)
-
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.
tak to tak nějak vyplývá z toho, jak to celé funguje. ale jestli to potřebujete nějak potvrzovat nebo vyvracet, můžete si vzít osciloskop a jít měřit. moje potřeba komukoli cokoli dokazovat je naprosto nulová.
-
no tak pánové, je zbytečný se hádat o spotřebě, stejně nevíme, co tam má za zdroj a jestli není třeba 12V CPU s disky jen na jedné větvi
potřeba je to vyzkoušet u pana Kratochvíla
navrhuji zatížit 7 z 8 disků náhodným čtením (seek) a z 8. disku číst data a kontrolovat md5
for x in {a..g}
do
ioping -w 1000 -R /dev/sd${x}& #1000 s by asi melo stacit k precteni 10GB z disku (100MB/s)
done
dd if=/dev/sdf bs=1M count=10240 skip=1048576 status=none | md5sum
případně měnit ze kterého disku kontroluji data, protože jsou různý
-
Ještě bych se podíval třeba
sensors před a během spuštění, jestli neklesá hodně některé napětí
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (https://cs.wikipedia.org/wiki/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.
-
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
-
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.
-
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
-
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.
-
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...
-
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 (https://cs.wikipedia.org/wiki/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)?
-
- 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?
-
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.
-
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.
-
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
-
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?
-
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 ;).
-
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>
-
- 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.
-
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)
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
-
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.
-
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ě
-
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.
-
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
-
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.
-
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 ::)
-
Jasně, jedná se o celoplanetární spyqnutí výrobců nekvalitních zdrojů se šindeláři. :o ;D ::)
On zkousel vice zdroju nebo jen zvanis?
-
Este by som sa vyskusal pohrat s io schedulermi a pre zaciatok by som zvolil deadline scheduler
-
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/
-
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.
-
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)
-
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
-
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.
$ cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber none
$ cat /sys/block/md0/queue/scheduler
none
-
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.
$ 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.
-
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 (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
-
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ý
-
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ě):
#!/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)
-
ještě jsem teď zjistil v souvislosti s chybou blk_mq, že nejde jen o nastavení
scsi_mod.use_blk_mq=0 ale radši ještě k tomu 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 (https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-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 (https://btrfs.wiki.kernel.org/index.php/Changelog#By_version_.28linux_kernel.29) to vypadá, že alespoň na funkce by mi 4.14 mělo stačit, podporuje dokonce už i kompresní algoritmus zstd (https://btrfs.wiki.kernel.org/index.php/Compression#What_are_the_differences_between_compression_methods.3F) a důležité opravy jsou snad backportovány (https://btrfs.wiki.kernel.org/index.php/FAQ#Are_btrfs_changes_backported_to_stable_kernel_releases.3F) 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í.