Názory k článku
Western Digital začíná s prodejem 18TB disků WD Gold SATA

Pro jaky ucel je takovy disk vhodny? Precist takovou obludu zabere urcite par dni...

K prvému: od chvíle, co tvůrci videí z oboru lidské anatomie přešli na 4k, to jistě spousta lidí naplnit dokáže.
K druhému: nižší modely téhle rodiny mají sekvenční přenosy cca 270MB/s. Tímto tempem je to teoreticky otázka minuty. Tedy volně řekněme, že při dobrém přísunu dat je to na hoďku max.

Nevypadly ti pri tom teoretickem reseni tri nuly?

ano, chybí, mea culpa, sekl jsem se o řád. Bavíme se tedy teoreticky o min 18hod zápisu celého disku. Čili cca 1 den.

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

O tri rady ;)

https://www.youtube.com/watch?v=hou0lU8WMgo

Teda seknout se i v opravě své chyby :-D

I kdyby to jelo těch 270 MB/s, tak mi vychází 18.5 hodin.

Tak nevím, ale 18000000 MB (18TB) při sekvenčním přenosu 270MB/s se kapacita celého disku přenese za 66666 s, tj. cca 18,5 h.

Asi bych si to dokázal představit i doma, ale máme třeba na serverech kolem 700 GB dat a to nejsme bůhví jak velká firma. Na zálohování a archivaci je pro náš use-case stále nejvýhodnější koupit jeden nebo dva malé servery a dát do něj pár těhle oblud než platit prostor v cloudu.

Za necelých 12K Kč jsem koupil nedávno 16TB disk Seagate Exos X16. Překopírovat tam asi 9TB dat zabralo asi pár dnů (jelo to asi 100-130MB/s). Ale pro mě je to jen jednorázová úloha a pak mi rychlosti na běžné čtení a zápis dat stačí. Holt SSD disky se zatím nemohou rovnat HDD pokud jde o poměr kapacita/cena.

Kdyz si chces ulozit dost dat. Vetsi disky jsou vetsinou o neco rychlejsi, nebot maji vetsi hustotu.

Kdyz se to porovna s beznymi 8TB disky, tak to vyzaduje jenom polovinu HW na obsluhu disku, takze i mene prostoru. Pri Onda B250 D32-D3 to mas kolem 1/4PB na server, s novymi disky uz jsme na 1/2PB na server.

Mit mensi 2 000 servrovy cluster s exabytem dat na procesing nemusi byt na skodu. Spolu je to kolem 100 racku, za 20 mil USD, se zbyvajicim HW cca 30 mil USD. To zni silene levne, hlavne pri pomysleni, ze jde o 1/2000 budgetu tajnych sluzeb USA. To se tam ztrati a mohou ulozit temer vsechno.

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.