Vlákno názorů k článku
Western Digital začíná s prodejem 18TB disků WD Gold SATA od Adam Kalisz - Rozhodně tyhle disky budou mít větší smysl, až...

Rozhodně tyhle disky budou mít větší smysl, až bude multi-actuator technologie v provozu. Teoreticky může být disk tolikrát rychlejší, kolikrát je tam víc těch nezávislých hlav.

I velká kapacita s poměrně pomalým přenosem může dávat smysl pro nějaké dlouhodobější zálohy typu AWS S3 Glacier. V domácím prostředí, kde jsou populární dvoudisková pole v RAID1 zase podobná věc umožňuje zase o něco vyšší kapacitu. Tam si tedy asi nebudou kupovat disky z řady Gold, ale v principu to možné je. Méně disků s vyšší kapacitou má také nižší spotřebu než více disků s nižší kapacitou. Když nejde tolik o rychlost, tak bych volil méně disků. Ono taky většina druhů zátěže zas tak skvěle s více disky v praxi neškáluje, jak by si lidi přáli. Tady jsou nějaká aktuální měření, v článku jsou odkazy na předchozí články, kde je ještě víc měření:

https://arstechnica.com/gadgets/2020/06/western-digitals-smr-disks-arent-great-but-theyre-not-garbage/

Na tyhle objemy už RAID1 (resp. RAID5, tj. jen s jednou paritou) nestačí.
Viz "Today, most consumer drives are rated 10^14 regarding their Unrecoverable Read Error Rate. That means that there is a chance that you get a read error every 12.5 TB of data."
Tj. v průměru (!) než se rebuilduje raid větší než 12TB, tak dojde k další chybě. Proto se musí používat buď víc parit a/nebo systém, kde se při rekonstrukci přenáší jen data a nesynchornizuje se prázdný prostor atp.

Ano, jsem si toho vědom. Je si toho vědom i běžný uživatel NASu s dvěmi šuplíky?
Další věc je, že u těchto disků se obyčejně udává URE rate jako <1 sektor na 10^15 přečtených bitů, tedy aspoň u Seagate a jejich 16 TB disků jsem to tak našel - mělo by to být zhruba srovnatelné.
https://www.seagate.com/files/www-content/datasheets/pdfs/exos-x16-DS2011-1-1904US-en_US.pdf

Jinak by nešlo ten disk přečíst samotný, aniž by došlo k chybě - taková vlastnost se přeci jen prodává špatně. Jinak u NASu bývá seznam kompatibilních disků, třeba u Synology DS218j (tedy efektivně nejlevnější/ nejhorší, co ještě reálně někdo může na 16 TB+ disky použít):

https://www.synology.com/en-global/compatibility?search_by=products&model=DS218j&category=hdds_no_ssd_trim&p=1

Je tam hned několik 16 TB disků.

Přesně tak, běžný uživatel o tom neví a prodejci malých NAS mu to evidentně nehodlají sdělit (viz to Synology).

Mohl by mi to někdo vysvětlit? Když dojde k té chybě čtení, tak to snad přece neznamená že celý disk je mrtvý. Mělo by to přece znamenat, že bude nečitelný jeden sektor, tj. odnese to příslušný soubor v souborovém systému, který bude poškozen. Tohle riziko se dá u domácího skladu multimédií akceptovat.

23. 6. 2020, 13:24 editováno autorem komentáře

Ano, může to být nějaký soubor nebo část souboru, nebo taky GPT záznam nebo třeba i jen prázdné místo. Může to být uprostřed jediné digitální verze Vaší diplomky nebo svatební fotky nebo nebo. Může to vést k problémům a nemusí. Já se s tím zatím vědomě nesetkal, ale nemůžu taky říct, že bych to všude monitoroval, takže věřím, že někde k tomu kolem mě už došlo, jenom o tom v blažené ignoranci (tam, kde za data neručím) nevím.

Běžný uživatel netuší, že úložná média nejsou 100% spolehlivá a ti, kteří to tuší, ti si neuvědomují, že ani funkční médium nemusí vždy vracet správná data.

Dost těchto problémů řeší různé kontrolní součty, kdy aspoň víte, že ta data jsou špatná. Některé souborové systémy, jako btrfs a ZFS je umí za určitých okolností automaticky opravit.

Zrovna u GPT to neni zas takovy problem. A u tech ostatnich veci to muze mit jednou jenom hazarder...

...ale souhlas s tim, ze tohle je a jeste bude problem a ze moderni FS jsou castecne reseni.

Ano, ale jaká šance je, že se ta 1 ku 10^14 chyba strefí do toho GPT záznamu?
Podle mě je naprosto mizivá šance, že se strefí do čehokoliv kritického.
Drtivá většina všech disků v téhle aplikaci (bfu s levným NASem) bude z téměř 100% zaplněna buď mulitimédii nebo prázdným místem a pak se ta chyba pokazí pouze těžko postřehnutelným glitchem ve videu, ještě o x-krát méně pravděpodobně člověk přijde o jednu z desítek tisíc fotografií.
Případ, že by takový disk s nedostatečnou redundancí byl naplněný z nezanedbatelné části nějakým kódem nebo databází, je podle mě extrémě okrajový.

V tom případě může RAID udělat (možná pro někoho paradoxně) víc škody než užitku, protože při chybě z pole vypadne celý disk.
Proto jsem (a i Adam Kalisz) zmínil jiná řešení (zfs, btrfs), která umí řešit i částečné chyby (kdy se počítají kontrolní součty při ukládání na víc míst a při chybě se dá porovnat, která data jsou správná). Ale nejsou uživatelsky přívětivá. Resp. neznám SOHO NAS řešení. A když o sobě tvrdí, že jsou na těchto filesystémech postavená, jestli je používají včetně inteligentního fail-overu.

Tak konkretne Synology pouziva u vyssich modeloch (t.j. nie 'j') btrfs. Sice nad mdraid, ale maju ho opatchovany, aby checksumy fungovali tak, ako maju.

Vid https://daltondur.st/syno_btrfs_1/

Ta chybovost ale neni o tom, ze dojde k chybe cteni - k tem dochazi porad a opravuje se to skrze kontrolni soucty a error correction na urovni sektoru.

Ta 1 chyba na 12TB dat znamena, ze cely proces cteni si bude myslet ze pracuje se spravnymi daty, ale nikdo o tom, ze to spravne neni nebude mit tuseni - ani disk, ani OS.

Reseni je pouzivat kontrolni soucty na datech - nebo donutit raid5/raid6 aby pri cteni povinne kontroloval zda sedi soucet (bezne se to nedela, jen pri testu pole skrze scrub). Ma nekdo informaci, zda lze takove chovani vynutit v Linux MD pres sysctl?

Me potkala takova bitova chyba na SAS disku v serveru - najednou zacalo padat php a imagemagick.so - sice si delam zalohy, ale pres rsync - dle timestampu se onen soubor nikdy nezpropagoval do zaloh (nebyl "zmenen"), takze reseni bylo udelat md5sum live souboru a zalozniho - a pak porovnat hexdumpy - lisil se presne o 1 bit, ktery zpusoboval spatny opcode a pad procesu :) A ano - radove to sedelo podle smart statistik (pocet prectenych dat za zivot disku) a specifikace chybovosti disku.

23. 6. 2020, 16:48 editováno autorem komentáře

Mozna hloupej dotaz, ale nemel by prave ten 1 bit byt poznat na urovni sektoru, jak pisete v prvnim odstavci?

Dobrá historka, díky.
Nejsem si vědom, že by normální raid uměl vždy porovnávat data s dalšími kopiemi. Něco z toho, jak jste sám popsal, lze "dobastlit" na aplikační úrovni.

V Linuxu se ale pomalu dostáváme do stavu, kdy máme poměrně slušné základy, ze kterých se spolehlivý systém dle potřeb dá poskládat. Btrfs, ZFS jsou v podstatě řešení "na klíč". Zajímavé jsou ale i projekty typu: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html kdy vlastně děláme na softwarové úrovni něco podobného mainframovým/ big iron diskům, které měli u každého bloku pár bytů navíc pro paritu.

Ext4 i XFS zase mají už nějakou dobu aspoň kontrolní součty metadat. Dave Chinner mluvil už asi před dvěma nebo třemi roky o možnosti díky tomu spolu s lepší integrací s blokovým ovladačem dohackovat pomocí virtuálních zařízení i data checksumy, Copy on Write, levné snapshoty apod. Některé z těch věcí už jsou v XFS nějakou dobu a fungují. Dá se tím dělat taková deduplikace pro chudé (reflink). Některé z těch věcí nejspíš využije projekt Stratis, který chce být alternativou k ZFS a btrfs, ale ještě má hodně práce.
https://lwn.net/Articles/747633/
https://www.youtube.com/watch?v=YGX1d9WEJYI
https://stratis-storage.github.io/

Taky máme distribuované souborové systémy jako Ceph, které ale klidně můžete provozovat i v rámci jednoho počítače. Ty samozřejmě tyto problémy taky zohledňují.

Rsync/ rsnapshot, Restic, Borg, Tarsnap apod. jistě lze nastavit tak, aby skutečně porovnávaly kontrolní součty.