Vlákno názorů k článku
Western Digital chce ve 30. letech vyrábět 140TB pevné disky od Buldr - Nějak si nechci představit rebuild pole po selhání...

Nějak si nechci představit rebuild pole po selhání disku, respektive není tak dlouho, co mi odešel na primáru 12TB HC530 (Areca 1883i) a naběl přepočet (2x hot-spare). Rozumím, že HW řadič s vlastní cache, bateriovou zálohou ... používají zejména dinosauři (T2/3) z důvodu spolehlivosti, na které se odlévají zálohy apod.

:) jsme druh na vymření. Kdykoliv někde vidím arecu, marně zatlačuji slzu.

Mně před mnoha lety přivedl na Arecu Dan Lukeš, dodnes jsem mu za to vděčný, protože konečně jsem našel plně funkční a spolehlivé řešení pro FreeBSD.

Predstavovat si to nemusis, takovyhle disky se do poli vubec nedaji pouzit. Ukaz mi dodavatele, kterej ti doda do pole vetsi nez 4TB mechanickej disk. Disk ti da rekneme (velmi optimistickych) 250MB/s ... To mas rebuild na 4.5 hodiny. I to je pomerne silenej cas a rozhodne dost na to aby ti mezi tim posel dalsi disk.

Vynasob to 10x a ses zhruba na aktualne dostupnych kapacitach. 45 hodin ... 2 dny.

I kdyby ten hypotetickej 140TB disk dal rekneme 1GB/s (tzn 4x vic), tak ses na tydnu.

uz nejake desetileti jede rebuild konstantne do 24 hodin - jak se zvysuje kapacita, tak roste i sekvencni rychlost

Samozrejme nemuzete pole v rebuildu trapit dalsim provoznim zatizenim

Ukaz mi dodavatele, ktery umi trim na SSD v R5/R6 konfiguraci :D na nejake mirrory (R1/R10) s**e pes :D sebelepsi ssd ti v poli bude neskutecne trapeno (ale zas, pokud mate sifrovani, ktere k necemu ma slouzit, tak na trim se muze zapomenou taky).

jak se zvysuje kapacita, tak roste i sekvencni rychlost

Toto platilo dokud se kapacita navyšovala změnou hustoty zápisu a i tehdy se rychlost zvyšovala jen druhou odmocninou nárustu hustoty, tedy celý disk trvalo stále déle a déle přečíst.

Poslední cca desetiletí kdy se kapacita primárně navyšovala přidáním dalších ploten se nárůst rychlosti disků zastavil, respektive roste jen tou změnou hustoty zápisu a ta narůstá hodně pozvolně, zato další plotny se dařilo přidávat docela dobře.

Reálně cca 200 MB/s dávali disky už před cca 10 lety. A dnes jsme na cca 270 MB/s ? Myslím běžné disky s 7200 ot/min.

Ono už je to hodně dlouho kdy jsem četl hezkou hlášku: "Hard drives are new tapes!".

Kdyz chcete rychlost, kupujte vice mensich disku. Nedavno jsem delal image 147GB SAS disku (15K), taky to valilo 200MB/s a za par minut bylo hotovo. Vsechno je otazka priorit - nadavate snad na to, ze cold storage s plackama nebo paskama ma minutove prodlevy?

Terabajtove SSD me popravde desi - jakou zavratnou rychlosti lze prijit o hodne dat naraz. Jednu vterinu jede, druhou nikoliv (at zije 32K hours bug). Porad mam vetsi duveru v rotujici rez, nez ten nestabilni dorticek.

Zalohy je dobre mit.. ale u SSD je to nutnost a nasazovana architektura spis pocita s tim, ze SSD cast je jenom spotrebni material - opotrebitelna cache, ale na primarni ukladani slouzit nebude.

========
Ono už je to hodně dlouho kdy jsem četl hezkou hlášku: "Hard drives are new tapes!".
========

S tím naprosto souhlasím. HDD na offline zálohy, přežijou bez napájení. Na živá data solid-state.

Nejsem odborník na HDD, ale čekal bych, že zápis i čtení budou probíhat paralelně přes všechny plotny. Tedy když chci zapsat jeden blok, rozdělí se tak, aby každá plotna měla stejně velkou část, a pak se paralelně zapíše na všech plotnách. Takto by navyšování počtu ploten zároveň mělo i navýšit sekvenční čtení i zápis. Nebo mi něco uniká?

Zapomel jste sva moudra sdilet treba s NetAppem :-) To nam vysvetlete, proc prodavaji pole s 60x 22TB NL-SAS disky... a to nepocitam externi shelfy :)

Ja bych chtel videt soudruhu, jaky ti na to daji support a garance ... A pak bych chtel videt nekoho, kdo bude takovou kravinu zcela kamkoli nasazovat ...

Ahoj, ten problém už samozřejmě existuje teď. Nové řady disků mají násobně vyšší nárůst hustoty záznamu (kapacity) a minimální nárůst rychlosti zápisu.
Takže prakticky ke konci jejich životnosti, kdy se obecně zvyšuje riziko závady, jsou při použití v diskových polích problematické dlouhé rebuildy (dlouhodobě se vytíží i všechny ostatní disky, které jsou zhruba stejně staré nebo přímo ze stejné série.. takže je tam i velké riziko nějaké další korelované závady). Tohle to posune jen ještě o krok dál.
Plus samozřejmě dlouhá doba, kdy tě ten rebuild stojí výkon a úložiště běží se sníženou redundancí v nějakém "degraded" režimu.

Tohle úzké hrdlo (rychlost zápisu do vyměněného disku) a vyšší riziko se v tuhle chvíli nedá obejít jinak, než že se použije režim RAIDu, který počítá s tzv. distribuovaných hot-sparem.
Zjednodušeně řečeno, hot-spare pak není celé jedno náhradní zařízení (disk), ale náhradní bloky připravené pro rebuild jsou od začátku umístěné (distribuované) na všech discích v RAID skupině.
Takže pakliže rebuild nastane, zapisuje to násobně rychleji přes víc fyz. zařízení. Byť se samozřejmě ten odešlý disk v nějakou chvíli musí vyměnit, už je to finální balancování (zápis do prázdného zařízení) mnohem bezpečnější a může jet delší dobu.
Už nějakou dobu je tohle ve vyšších modelech diskových polí třeba od IBM (tam tomu říkají De-Clustered RAID) nebo DDN (určitě budou i další, tohle je jen co znám). U softwarových implementací je tohle dostupné například v ZFS (dRAID).
viz https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html

Takže tohle je cesta do budoucna, dokážu si představit, že s vyššími kapacitami disků tohle může probublat i do nějakých samostatných RAID řadičů (jako tvoje Areca) nebo nějakých entry-level polí, pokud už to nebude všechno softwarové - mimo nějakého mirroru pro boot ;).
A jasně, pokud to někdo bude mít obrovské disky v jednoduchých úrovních RAIDu (1, 10) s malým počtem disků neřeší ho to.

Mně musím zaklepat odcházeli disky hlavně po odstávce Dell PowerEdge, tedy přeznačený Seagate (ES2/ES3 či něco podobného). Vlastně se tomu ani nedivím, když jejich špičková kvalita získaná z kontejneru elektroodpadu, kterým říkají zdroje. Poslední, kterých jsem se zbabil Dell PE220 + PE230 a nikdy více.

Úložiště a zálohování si řeším po svém, složím, trápím, měřím, … a jestli mi za ty roky odešli dva UltraStary, tak je to opravdu hodně. 12TB HC530 mám výhradně na zálohování a archivy (část jde na LTO3), čili k nim přistupuje zejména Bacula (ARC1883i). Spolehlivost. Provozuji 6x 7400 Pro U.3 (PCIe x4), konkrétně 3.84 TB (MTFDKCB3T8TDZ-1AZ1ZABYYR) a 10x 7400 Pro M.2 1.92 TB (MTFDKBA1T9TDZ-1AZ1ZABYYR). Prvním problémem bylo připojení na řadič (Tri-Mode). Kovbojka s Areca 1886-16l 12Gbps PCIe 4.0 x8 (8654-8612), mám nekompatibilní řadič, kabely, disky, … udělal jsem někde botu? Po dlouhém hledání jsem našel hodně stížností a problémů, protože disky odmítají fungovat x1/x2 a to platí i pro 24 Gbps PCIe x16 Broadcom a jsou problémy s kabely (zapůjčený řadič k ověření Broadcom 9560-16i + 05-60005-00 ano, 05-60006-00 si člověk neškrtne). Varianta U3 tak skončila na desce = 16x NVMe x4 = 64 linek 80 Pin OCL (Tyan SX8026) a ZFS, ze kterého radost nemám, je to moc moderní (čti překomplikované) a mohu-li si vybrat, tak volím jednodušší a spolehlivější řešení s řadičem. Se ZFS jsem si už něco užil (Solaris, BSD, Linux) a nikdy mi k srdci nepřirostlo.

Celkem se orientuji, nicméně držím se toho co umím (vyřešit problémy) a spolehlivosti. S Micron jsem zkušenosti neměl, nechal si poradit a natloukl si čumák. Můžeš to nazvad dinosauří modernou, protože mechanické disky už mám opravdu právě jen na odlévání záloh, kde prim hraje kapacita a spolehlivost.

6. 2. 2026, 20:57 editováno autorem komentáře

Já to psal spíš obecně, jako jediný mě známý mechanismus, jak zkrátit kritickou dobu rebuildu u velkých točivých disků v RAIDové vrstvě. A ano není to určitě vhodné do všech situací, nese to s sebou nezbytně další komplexitu, dává to smysl převážně do větších úložišť atp.

Podobně pak u nějakých implementací EC (Erasure Code) na úrovni šklálovatelných, clusterovatelných FS. Kdy se pak použijí všechny "přeživší" disky s volným místem, aby se doplnila požadovaná redundance u postižených kousků dat (chunks), což pak jede také paralelně.
A ano nese to s sebou opět další potenciální problémy. Např. saturaci nějakého propojení mezi nody, rychlost toho "rebuildu" může progresivně klesat pokud je ten fs hodně zaplněný, případně specificky fragmentovaný. U točivých disků to může strávit poměrně hodně času seekováním atp.
Což neříkám, že je to principiálně špatně (naopak), ale může tam být prakticky spousta detailů okolo.
Oproti tomu ten "klasický" rebuild RAIDu je sice pomalý, ale jde o relativně přímočaré sekvenční zápisy na blokové úrovni, co jsou vcelku predikovatelné (samozřejmě za provozu je tam nějaký QOS v souběhu s uživatelskými operacemi).

Jinak chápu, už jsi o tomhle trápení s NVMe disky psal, obecně tyhle skládačky jsou vždycky trochu sázka do loterie, pokud se explicitně nedržíš nějakých seznamů od výrobce. A řekl bych, že u toho NVMe je ten potenciál případných nekompatibilit v porovnání s klasickým SAS/SATA v celém tom řetězci - disk, backplane, kabely, řadič nebo deska (kde zas případně řešíš různé bifurkace) ještě násobně větší a specificky ještě s tri-modovými řadiči (byť tedy já mám zkušenosti jen s LSI/Broadcom a Adaptecem).
Na stranu druhou asi bych nutně nebyl smutný, že to mám připojené "natvrdo" do sběrnice a řeším to třeba přes ZFS. Specificky u těch SSD je to kolikrát nejlepší varianta i kvůli tomu, že ty RAID řadiče zas schovají všechny ty registry z disků, nedostaneš se na užitečné informace a logy z nich (např. pro určení WAF v hardware, pokud to přímo neukazuje řadič), podobně pak nefunguje deallocate (TRIM).

Nakonec, není to tak, že bych myslel, že klasické HW RAID řadiče s baterkou nebo supercapem jsou překonané. Také pořád na většině míst v pohodě a vcelku predikovatelně běží. Podobně s konvenčními filesystémy. Byť nastávají i situace, kdy ta případná další komplexita má praktické opodstatnění třeba pro to škálování, nebo třeba ZFS send-receive.. jestliže vyloženě člověk nechce jít do nějakého celého (a typicky patřičně nákladného) proprietárního řešení.

Ty značkové s „garantovanou kompatibilitou“ jsou trochu mimo možnosti a určení menších firem v dobré finanční kondici, nicméně o bezproblémovosti si myslím svoje, ačkoliv připouštím minimální vzorek a také fakt, že šlo o servery a úložiště „na nižší“. Kritický bych měl být především sám k sobě, nastavený „dělat to pořádně“, nebo raději vůbec a upřímně říkám, že můj „crash+disaster“ plán počítá se vším, kromě zničení Země a slevit neumím.

Mně to zase tak moc nevadí, stále trochu cítím k ZFS hořkou pachuť minulosti a nutnost se toho hodně doučit a oprášit (spoustu času jsem strávil hledáním jak to rozbít a dát dohromady) a pravdou je, že U3 mám hlavně na železe s Windows Server (na to mám firmu), stejně tak na SLES. HAF-HAST (FreeBSD) a Backup (FreeBSD) si řeším sám a po svém, což je víceméně otázkou znalostí, zkušeností, času a schopností vyřešit problém okamžitě.

Na to jsem ani nepomyslel, prostě každé řešení má své klady i zápory, také je nutno přičíst podmínky nasazení.

P.S.: Překvapilo mě, jak ty nejobyčejnější Kingston DC600M (ARC1883i) fungují. Jakkoliv jsou vlastně tupé a nic neumí, spolehlivostí překvapují. Zkrátka jsem si trochu rozbil ústa na Micronu a komplikováním již tak překomplikovaného NVMe … zasloužený trest.

No ale ZFS dRaid má zase fixní bloky , takže tě vrací zpět k této nevýhodě klasických RAID čipů.
Hádám, že HW based de-clustered to budou mít taky tak, nehledě na mnoho buzzwords v datasheetech ;)

Není to sranda s těmi úložišti ani když jsou hodně SW defined - všechno má svoje pro a proti - zlepšovák na jedné straně se vykoupí slozitostí na straně druhé.

Tak dRAID z principu musí mít fixní bloky, pokud to počítá s nějakým pravidelným prokladem (je tam daný počet spare bloků). Také ten rebuild vůbec nejde dovnitř, nekontroluje checksumy jako klasický resilver. Proto taky na konci spustí rovnou scrub.

U HW raidů s distr. sparem totéž, tam by ta variabilní délka bloku ani nešla technicky zařídit. Ta pole fungují s předdefinovanou velikostí stripe/segmentu a neřeší, jestli je nad tím souborový systém a co zrovna alokuje, nebo třeba image z virtuálů, kolik je reálně obsazeno daty atp.

Jinak dRAID se podle mě principiálně hodí na větší úložiště s mnoha točivými disky, aby se projevily případné výhody. Tzn. sedí mi to na nějaké větší soubory, média, nearline archiv... (bulk storage). Nepojedu z toho databáze, virtuály a nic, kde by měly být kritické IOPSy.
Pro tenhle workload typicky používám stejně větší recordsize a klidně s pevnou délkou, naopak mě netrápí zrovna efektivita třeba 4k nebo 16k zápisů, resp. nějaký zvýšený overhead.
Navíc to stejně můžu doplnit třeba párem nebo trojicí mirrorovaných SSD, které dedikuju v ZFS jako special device, takže tam půjdou tyhle krátké zápisy a metadata (což zrychlí související operace s FS)

A souhlas, neexistuje jedno řešení pro všechny úlohy. Standardní RAIDy a FS mají pořád své místo. U dlouhých rebuildu ta rizika řešit klasickými cestami - dvojitá parta, rozumné RAID skupiny, replikace/zálo­hování.