Dotaz: Rychlost zápisu raid-60

[gepard]

Ahoj, řeším raid pole potřeboval bych to zkonzultovat.
Na internetové kalkulačce raid-60 to píše, že "no write speed gain". Nějak mi to nesedí.
Jsem ochotný připustit, že u raid-6 by to mohlo mít i nižší rychlost zápisu než jeden singl disk.
Ale u raid-60 mi to nesedí. Nicméně raid-60 mám k dispozici a má rychlost ~150 MB/s. Je to strašně málo.
A dle dostupných informací, počet disků v raid-6 a raid-60 poli nemá na rychlost zápisu vliv.
Nicméně mi přijde, že raid-60 by měl mít přibližně dvojnásobnou rychlost zápisu.

---

---

Odpovědi

[Andrej]

Protože je to hnus. On už je hnus RAID5, superhnus je pak RAID6. Následně záleží na konkrétní implementaci. Phoronix dělal relativně nedávno nějaké reálnější testy:
Linux 5.5 SSD RAID 0/1/5/6/10 Benchmarks Of Btrfs / EXT4 / F2FS / XFS.

Když použiješ RAID6, tak ti vznikne hovno. Když to hovno budeš chtít vynásobit RAIDem10, tak budeš mít hovna dvě.
V dnešní době tyto úvahy moc nechápu. Máme tu BTRFS i ZFS, kde lze podobné věci řešit mnohem lépe. U BTRFS má RAID1C3, u ZFS máš RAID-Z2 (kde můžeš velký výkonnostní problém řešit SSD keší, resp. SLOGem).
Zdar Max

[Peter Golis]

Ale no tak, tie impresie si si mohol odpustiť.

RAID 50 a 60 sa bežne používa v priemysle kde človek má RAM Cache na radičoch, a chce občas pridať shelf s diskami. Bez toho cache na RAID radičoch sa to spomaľuje na synchrónnych zápisoch, a výkon v IO operáchách je dosť mizerný.

[Max]

Tento druh polí mi v dnešní době nedává smysl. Je to velká bolest. Dalo by se to použít jen jako archivní pole, ale spousta lidí chce i od samotné archivace nějaký výkon. Dřív, když byla cena disků obrovská za malou kapacitu, dalo se toto šetření chápat. Dnes už to smysl nedává a není to rentabilní nejen z hlediska výkonu, ale i z hlediska např. výměny vadných disků a následný sync pole.
Zdar Max

[Peter Golis]

Pokiaľ sa bavíme o drobnom objeme dát, tak s tebou súhlasím. Sám som si doma podobne vyriešil NAS.

Ale sú priemyselné segmenty kde potrebuješ mať v databáze napr. 10 ročnú históriu transakcií, a tam by si asi nechcel mať FS ktorý to spomalí. Tam by si radšej išiel do niekoľkorackového modulárneho diskového poľa s HW RAID (a kadejakými RAM+NVMe cache), a datafajly by si dával priamo na LUNy ako RAW Device. No, ale to je pravda úplne iný segment trhu.

[[Jooky]]

Tento druh polí mi v dnešní době nedává smysl.

Ako je potom lepsie usporiadat pole, kde su stovky diskov ?

U zakaznika mame NetApp diskove polia. Samotne disky su po 8 az 24 kusov usporiadane do RAID-DP grup (viacmenej RAID6, stripe + 2x parita). Samotne raid grupy su spajane do kombinacie linear / stripe plexov (na tejto urovni sa pouzivaju velke bloky, takze zalezi od zapisu, ci ide stripe, alebo linear). Nad tym celym sedi filesystem, ktory vzdy zapisuje do volneho miesta. Tym padom nie je potrebne narocne prepocitavanie v style "read-modify-write" a rychlost zapisu vobec netrpi. Citanie z takeho pola dokaze saturovat aj 4x 10 Gbit ethernet trunk ...

Podla mna cely problem je, ked si niekto spravi RAID5/6 z maleho poctu diskov a da na to nevhodny filesystem ako napr ext4. To potom strasne utrpi vykon ... Nad RAID5/6 musi sediet nieco, co nebude robit nezmyselne operacie a tym zabijat cele pole.

[Max]

V RAID6 nesmíš mít málo disků a ani hodně disků (optimum je kolem 8 disků). Porovnávat to s RAID-DP (což sice je něco jako alá RAID6, ale s menším výkonnostním propadem) s WAFL je trochu mimo. Osobně NetApp také mám, mám též RAID-DP, znám ho, aktuálně už máme NetApp na druhé koleji a používáme lepší level.
Jak jsem psal, řešil bych to pomocí btrfs (RAID1Cx) nebo u velkých polí pomocí ZFS (Pool poskládaný z RAID-Z2 po 8 diskách). To pak můžeš jednak škálovat do alelujá, dále to máš nesmrtelný (velká odolnost vůči výpadkům disků). A když máš velký počet disků, nemusíš řešit ani SLOG, protože je běžným 2x 10Gbit síťovým vstupem nevysaturuješ.
Tj. se ZFS bych vůbec neviděl problém, kdyby jsi měl poskládaný pool třeba z 13x (8x 8TB hdd RAID-Z2), tj. celkem ze 104 disků a k tomu třeba ještě dva jako online spare. Odolnost vůči výpadku by jsi pak měl 2-26 disků.
Zdar Max

[PetebLazar]

Tu kalkulačku bych bral s rezervou, na šestičlenném RAID6 (z 8TB He SATA) dociluji sustain sekvenčního zápisu cca 500MB/s. Což je podstatně více než výkon jediného člena.

[ChatBot GPT-3]

Raid-60 je konfigurace, která kombinuje vlastnosti raid-6 a raid-0. V raid-6 se používá dvojice disků pro parity data a umožňuje tolerovat selhání až dvou disků. V raid-0 se naopak používají více disků pro zvýšení rychlosti čtení a zápisu, ale bez parity data, takže selhání jakéhokoli disku způsobí ztrátu dat.

Raid-60 tedy kombinuje tuto redundantnost raid-6 s rychlostí raid-0 a umožňuje tolerovat selhání až dvou disků při zachování vysoké rychlosti zápisu. Při počtu 12 disků byste tedy měli očekávat výrazné zvýšení rychlosti zápisu oproti raid-6, ale rychlost zápisu bude stále omezená na rychlost jednoho disku, protože parity data se zapisují na dvě disky.

Pokud se vám zdá, že rychlost zápisu vašeho raid-60 pole je příliš nízká, může to být způsobeno několika faktory, jako je kapacita a rychlost jednotlivých disků, výkon raid kontroleru nebo některý z dalších faktorů, jako je například kapacita cache nebo propustnost sběrnice. Může být také vhodné zkontrolovat, zda nejsou na vašem raid poli nějaké disky s nízkou rychlostí nebo selháním, které mohou způsobovat problémy s rychlostí zápisu.

V případě, že se chcete dozvědět více o různých konfiguracích raid a jejich vlastnostech, můžete se podívat na stránky, jako je například https://raid.wiki.kernel.org/, kde najdete podrobnější informace o raid polích a jejich výhodách a nevýhodách.

[PetebLazar]

V raid-6 se používá dvojice disků pro parity data

Pozn. Ještě přesněji, v RAID-6 se nepoužívá dvojice disků pro paritu, parity RAID-6 jsou umísťovány na všechny členy (HDD). https://upload.wikimedia.org/wikipedia/commons/thumb/7/70/RAID_6.svg/652px-RAID_6.svg.png

ale rychlost zápisu bude stále omezená na rychlost jednoho disku, protože parity data se zapisují na dvě disky.

Pokud se dejme tomu bude ukládat 1MB užitečných dat na šestičlený RAID-6 může to být realizováno zápisem 256KB+256KB+256KB+256KB datových informací a 256KB+256KB paritních informací. Na každý člen tak bude zaznamenána pouze 1/4 objemu ukládaných dat (+režie FS).

[lertimir]

Ještě drobné upřesnění. Obrázek to vysvětluje, ale tak, jak jsi to napsal, vede trochu ke zmatení, jak je parita "rozptýlena". RAID-6 přece používá dva disk pro paritní data, ale v různých stripech jsou pro paritní data použity jiné dva disky z poolu, protože zátěž na paritní disky je vyšší než na datové a tímto se zátěž poolu vyrovná.

[PetebLazar]

Z jakého důvodu by IO zátěž i při atomických operacích (R/W) měla být u paritních členů konkrétního stripe jiná než u datových členů téhož stripe?

[lertimir]

Chápu to jako důsledek vývoje, který dal vznik a použití RAID-5 proti RAID-4, které nyní nikdo nepoužívá. RAID-4 je n-disků s jedním paritním, tedy velmi podobné jako RAID-5, ale s tím rozdílem, že veškerá parita je pro celý objem umístěna na jednom jediném disku. A dokumentace praví, že tato konfigurace má za následek bottleneck v zápisech na paritní disk (což beru jako zvýšenou zátěž proti datovým) a na jeho odstranění vzniká RAID-5 s rozptýlením parity a RAID-6 je na tom s rozptýlením podobně.

[PetebLazar]

Ale objem paritních informací u RAID5(RAID6) na člena je shodný s objemem užitečných_dat/člena (tj. operací je shodně, jdou prakticky do "identického místa"(CHS) na HDD, mají stejný charakter[R/W] a velikost). Nějak v klasických implementacích RAID5(6) nenalézám opodstatnění pro tvrzení výše.

Na Internetu jsou k nalezení zajímavé perly.

A RAID 4 array requires at least two disk drives: two for striping data and one for parity.

A aby toho nebylo dost, pokračují srovnáním RAID5 s RAID4. Chtějí tím snad říct, že RAID4 neustojí ztrátu jednoho libovolného člena?

About RAID 5 Arrays

Similarly, a RAID 5 array also uses block striping. The major difference is in the parity data, which is distributed across all drives in the RAID array, rather than confined to one disk. This makes a RAID 5 array better protected against data loss, since a RAID 5 array can tolerate the loss of any single disk drive in the array. There is no single parity drive that may fail.

[Peter Golis]

Nebude ten rozdiel v tom že RAID-4 mala disk vyčlenený na len na paritu, a RAID-5 rozkladal paritu na rôzne disky? To v prípade výpadku paritného disku RAID-4 znamenalo prerátanie celého poľa a dopočítanie parity (aj s možnými poruchami na dátových diskoch ktoré sa tým utajili a zlegalizovali).

[PetebLazar]

Ale vždyť když vypadne člen z RAID5(6) tak se po náhradě za jiný prázndý disk tento bude celý zapisovat s tím, že pouze zapsaná 1/Ntina dat budou parity, zbytek užitečná data.

[Peter Golis]

Pri RAID-5 tým pádom prerátavaš len 1/Ntinu prislúchajúcu parite, a zvyšok z tej parity dopočítaš. No, a to riziko keď sa ti zlegalizujú chyby na ostatných diskoch (či už dávnejšie silent data corruption, alebo škrknutie pri HW probléme ktorý odpálil RAID-4 paritný disk je menšie. Preto RAID-4 nahradil RAID-DP.

Čo sa týka výkonu a flexibility, tam skôr závisí na použití cache a rozkladaní zápisu na viaceré disky. Kedysi som videl Proof of Concept kde chlapík dokázal že zápis CD je pomalší ako zápis na diskety. Spravil RAID-5 z viacerých 3.5' USB diskiet a otestoval rýchlosť.

[PetebLazar]

Tipnul bych si, že ty případné silent chyby jsou již dávno legální. Recovery s pomocí parity(mirroru) u RAIDu snad nastupuje pouze v případu selhání operace nad členem (total member fail, CRC error atd.).

U RAID6 je tu asi stále teoretická možnost sestavit pole read-only pouze z vybraných členů (simulací fail member se vyhnout se rot-bitu na postiženém z členů).

Možnost přehlasování datového obsahu membera dvěma existujícími paritami není v mdadm implementováno (při zjištění nekonzistence se snad vypočtou nové parity).

[Peter Golis]

Tipnul bych si, že ty případné silent chyby jsou již dávno legální.

Pokiaľ implementácia RAID nekontroluje paritu pri čítaní alebo pokiaľ disk neinformuje SMART až agresívne (checksum má byť na každom bloku HDD, a na rozumných diskoch sa zvykol kontrolovať aj pri čítaní), tak áno. Ale také niečo by som nepoužil na dôležité dáta.

U RAID6 je tu asi stále teoretická možnost sestavit pole read-only pouze

V minulom tisícročí som zažil HW pole s RAID-5 čo malo len jeden spare. Vypadli mu dva disky, a stále bolo schopné zápisu aj keď dosť spomaleného. Technik z Compaq nebol nadšený nad situáciou, a divil sa že to DEC pole prežilo.

Možnost přehlasování datového obsahu membera dvěma existujícími paritami není v mdadm implementováno

To by znamenalo že MDADM nepodporuje RAID-6. Tá šestka znamená že sa používa dvojitá parita s dvoma rôznymi typmi checkumov. Ak jedna parita nesedí, tak sa použije druhá a rozhodne sa podľa výsledku. Od toho sú v RAID-6 dve parity.

[PetebLazar]

Pokiaľ implementácia RAID nekontroluje paritu pri čítaní alebo pokiaľ disk neinformuje SMART až agresívne

Parity RAID6 jsou snad triviální XORy, na rozdíl od 100 byte ECC nad 4K sektory HDD. Detekce vicebitových chyb (na více členech) RAID asi nepokryje, spolehá se na zdání správnosti ze strany HDD).

V minulom tisícročí som zažil HW pole s RAID-5 čo malo len jeden spare. Vypadli mu dva disky

Možná dva disky měly v RAID5 místní problémy, ale nemohly zcela vypadnout (drive failure) pred sync na spare to by chybela data. Zapis na RAID5 s N-2 funkcnimi cleny bude asi dost write-only.

Tá šestka znamená že sa používa dvojitá parita s dvoma rôznymi typmi checkumov. Ak jedna parita nesedí, tak sa použije druhá a rozhodne sa podľa výsledku.

Může te toto tvrzení ozdrojovat? Z toho co jsem nalezl já to tomu aspon u mdadm není.

[Peter Golis]

Detekce vicebitových chyb (na více členech) RAID

S tým agresívnym SMART som narážal na to, ako Linux vykopával enterprise disky z diskového poľa aj keď im nič nebolo. Také disky mali sprísnené štatistiky a informovali aj o oneskorení čítania, nielen o nesediacom čítaní alebo zápise. HW diskové polia z toho robili štatistiky a vedeli presnejšie a oveľa skôr predpovedať zlyhanie. Najmä ak niektoré desktopové alebo externé USB disky o chybách čítania/zápisu ani neinformovali. Občas také chyby zatajoval aj desktopový OS z Redmondu.

Možná dva disky měly v RAID5 místní problémy, ale nemohly zcela vypadnout (drive failure)

Bolo to malé 4U pole, a na prednom paneli nielen blikal výpadok dvoch diskov (spare bol len jeden), ale zaplo sa aj pískanie. Problém bol v tom, že to pole bolo úplne u podlahy a nikto naň pri zbežnej obhliadke nepozeral. Remote monitoring v minulom tisícročí nebol moc obvyklý.

Tá šestka znamená že sa používa dvojitá parita s dvoma rôznymi typmi checkumov.

Pardon, používal to napr. NetApp pri RAID-DP. Kedysi to chceli implementovať aj do Linuxového SW Raidu, ale nesledoval som či to dorobili. Na Linuxe je SW RAID súčasťou blokových vrstiev MD, DM a aj LVM.

SW RAID-6 je naozaj Striped Set With Dual Distributed Parity.

[Max]

Souhlasím, na netu lze najít spoustu nesmyslů. Já narazil na tyto zajímavé informace:
Understanding RAID Penalty.
Calsoft Whitepaper: Performance Tuning for Software RAID6 Driver in Linux
Linux 5.5 SSD RAID 0/1/5/6/10 Benchmarks Of Btrfs / EXT4 / F2FS / XFS.

Záleží tedy i na konkrétní implementaci RAID6 (v případě Linuxu záleží na verzi kernelu, spoustu informací je ohledně obsolete implementace), jakým způsobem vypočítává parity atd. Další problém může nastat s manipulací s polem, třeba navyšování o další disk, kdy během navyšování nemusí být redundance plně k dispozici atd.
Stále si trvám na svém, že RAID6 je hodně pomalé a těžkopádné pole a podobně jako RAID5 nemá v dnešní době smysl jej provozovat.
Také souhlasím, že výkon pole při zápisu bude větší, než rychlost jednoho disku (pokud budeme mít odpovídající počet disků).
Zdar Max

[PetebLazar]

J́á bych tomu oponoval, že záleží na konkrétním use case. V pracovní stanici využívám RAID6 (6x8TB_He + 1x hot-spare + 1x cold-spare) pro uložení (write-once) archivu vygenerovaných dat (získaných protažením vstupních dat skrze workflow). V případě potřeby by šel celý obsah RAID6 za několik dní(týdnů?) vygenerovat znovu (dílčí obsah cca za hodinu).

Omezený strach z rot-bitu a spol. možná pramení z toho, že samotná vstupní data mají cca 100+ násobnou redundanci a zhruba pouze 95% přesnost. Ublížit jim natolik, aby to ovlivnilo výsledek by stálo značné cílené úsilí. Jde o značně vymykající se use case, ale i takové jsou.

[Max]

Proč pro takový případ nepoužít třeba btrfs RAID1C2?
Zdar Max

[PetebLazar]

Teď mám nepočítaje hot(cold)-spares ztrátu prostoru 1/3 kapacity použitých členů (RAID6 se šesti členy), nepřinesl by BTRFS RAID1c2 ztrátu 1/2 kapacity zúčastněných HDD?

[PetebLazar]

Oprava: RAID1c2 znamená originál + 2 kopie? Takže bych měl jen 1/3 kapacity všech členů? Redundanci schodnou (tj. při výpadku dvou členů stále čitelná data)?

[Max]

Samozřejmě jsem se spletl, myslel jsem Raid1C3 = 3 kopie, tj. obdoba RAID6.
U btrfs si můžeš definovat raid level zvlášť poro data a zvlášť pro metedata. Můžeš si tedy zvolit třeba RAID1C3 pro data a RAID1C4 pro metadata.
Klasický RAID6 se spare diskama je drahá věc. Proč kupovat disky, které nebudu využívat, budou běžet, ale naprázdno? Proč nepoužívat všechny disky najednou a nemít zároveň zajištěnou i redundanci? A o tom btrfs a další moderní technologie (např. i Nimble) jsou.
Máš btrfs, RAID1C3 a 6x hdd. Pokud si ohlídáš dostatek volného místa, tak ti mohou odpadnout dva disky a budeš pořád v cajku, po rebalancu ti pak mohou odpadnout další atd.
Zdar Max

[Max]

Jinak RAID1CX chybí třešnička na dortu, protože "reading from mirrors in parallel can be optimized further" a "The simple redundancy RAID levels utilize different mirrors in a way that does not achieve the maximum performance. The logic can be improved so the reads will spread over the mirrors evenly or based on device congestion.".
Takže je tam ještě rezerva pro výkonnostní optimalizace.
Zdar Max

[PetebLazar]

Je neuvěřitelné jak málo k RAID1C je na Internetu dohledatelných informací (viz. prvně správných 50% pro RAID1c2 efficiency a pak opravené na chybných 33%), aby se ukázalo že výraz RAID1c2 (Google najde celých 72 výsledků) ani není skutečným (mělo být použito označení RAID1, ale u toho by zase zmizela BTRFSovost).

RAID1c3 má mít údajně data efficiency 33% (tři kopie dat), RAID6 na šesti členech 66%. https://wiki.tnonline.net/w/Btrfs/Profiles

Wiki u wiki.kernel.org má pro kernel 6.0 u Device Replace status mostly OK.

Uznávám, že pro toho kdo uvažuje o dvou spare pro 104 HDD toto může být opravdu luxusem, čas ukáže nakolik byl ve výhledu cca 5+ let zbytečným.

[Max]

RAID1CX je tu s námi relativně krátce (kernel 5.5).
Tomu s tím 104 hdd a dvou sparech nerozumím. Když třeba skládám ZFS, tak z RAID-Z2 a každý z nich po 8xhdd, né více. Osm je dobrá kombinace výkon a rychlý resync v případě, že neprojde replace.
Z toho důvodu si třeba myslím, že btrfs není vhodné na velká úložiště (ve smyslu počtu disků), protože u většího počtu disků už pak nestačí ani RAID1C4 (prostě u 104 disků nestačí, že nám mohou tři odejít, to je prostě malá redundance).
Podobně bych pro větší nasazení nepoužil mdadm. Pro menší nasazení btrfs (do 20ks hdd), pro větší nasazení ZFS (relativně neomezeně hdd).
Dnes bych už nikde mdadm nepoužil, už v něm nevidím smysl.
Ohledně té efektivity. Pokud budeš mít RAID6 a k němu spare disky, které se ti budou flákat (= nemůžeš na ně nic uložit), tak na tom s efektivitou budeš hůře, než s btrfs u stejného počtu disků a budeš na tom i hůře s nerovnoměrným opotřebením.
Zdar Max

[PetebLazar]

To jsem asi jen nepochopil jak jste to myslel ve Vašem příspěvku výše .. tj. celkem ze 104 disků a k tomu třeba ještě dva jako online spare.

[Max]

To se vztahovalo k ZFS, né btrfs.
Zdar Max

[PetebLazar]

Netušil jsem, že spolehlivost disků má významnou souvislost s použitým FS.

[Max]

To jsi si špatně přebral. Nemluvil jsem o spolehlivosti, ale redundanci. Opravdu nechceš mít 104 disků a jen dva pro redundanci. Na NetAppu u 24 disků se mi stává, že většinou odcházejí dva najednou. Ten druhý většinou po resyncu toho prvního. Někdy během resyncu. S větším počtem disků máš větší šanci na to, že ti najednou odejdou tři disky a budeš v loji.
Pokud používáš ZFS, tak můžeš např. stavět pool z RAID-Z2 skupin po osmi diskách. Pokud máš těch skupin třeba 5, tak ti může vypadnout 2-10 disků a pořád budeš mít neporušený data.

U btrfs nic takového neposkládáš. Potřeboval by jsi k tomu další vrstvu, třeba to mdadm, kde by jsi v obdobném případě jako u ZFS vytvořil 5x RAID6 po osmi diskách. A výsledná pole by jsi pak přidal do btrfs raid0. Tím by jsi získal obdobnou funkcionalitu jako u ZFS. Samotné btrfs ale toto neumí. Proto pokud mám menší počet disků, tak si vystačím s btrfs raid1cx. Pokud mám větší počet disků, sáhnu po ZFS, které je pro velké storage navržené.
Zdar Max

[xxl]

A nešlo by se v tebou popisovaném příkladu vytvořit skupiny osmi disků s btrfs raid6 a z těch skupin poté sestavit vyšší vrstvu btrfs raid6? V principu by to přece mělo fungovat. Akorát to nemusí mít správný výkon, což ale nedokážu posoudit.

[Max]

Když pomine, že zlí jazykové tvrdí, že btrfs raid5/6 je unstable, tak nevím, jak něco jako RAID60 s btrfs udělat. Dle ofiko dokumentace to nejde. Ty navíc nemyslíš RAID60, ale RAID66? To je trochu překombinované s obrovskou ztrátou kapacity, řekl bych...
Zdar Max

[xxl]

Ono by to vlastně nejspíš ani nešlo přímo sestavit tak, jak jsem to napsal. Chtělo by to další mezivrstvu, aby se z té spodní vrstvy btrfs vůbec dala sestavit ta horní vrstva btrfs.

[Aleš Kapica]

Ono by to vlastně nejspíš ani nešlo přímo sestavit tak, jak jsem to napsal. Chtělo by to další mezivrstvu, aby se z té spodní vrstvy btrfs vůbec dala sestavit ta horní vrstva btrfs.

WTF?

[PetebLazar]

Efficiency RAID6 RAIDu6 by záležel na počtu členů v jednotlivých svazcich. Pokud by v každé vrstvě bylo vzdy deset členů (8+2 bez spare) tj. celkem 100 HDD, ztratila by se v první vrstvě 1/5 prostoru a v druhé vrstvě ze zbývající další 1/5 (100*0,8x0,8=64HDD .. efficiency 64%). Taková šílenost by snad měla být odolná minimálně na současný výpadek libovolných 8 HDD (až 36 těch správných HDD .. vypadek 2 disku u osmi RAID6 svazku v prvni vrste + vypadek 10 disku u dvou RAID6 svazku v prvni vrstve). Pokud jsem se tedy nepřepočítal.

[Max]

Chtěl bych vidět skládat to pole a jeho resync :).
Zdar Max

[Aleš Kapica]

Podle mě je to Maxi naprosto zbytečná úvaha, protože Btrfs funguje jinak než klasický MD raid. Je to teda pouze empirická zkušenost, ale Btrfs data rozhazuje tak, aby byl prostor obsazen rovnoměrně. Takže čím víc disků, tím menší potřeba většího množství kopií jednoho chunku, jelikož pravděpodobnost, že by ti najednou chcíply dva disky, na kterých by byly ty kopie, je velmi malá. Neříkám tím, že neexistuje ale osobně se mi za celou dobu co Btrfs používám nikde nic takového nepřihodilo.

Přitom příležitostí by byl k tomu hafec. U MD RAID6 mi k veselici stačilo jenom zavadit kabel co vedl do modulárního zdroje. U Btrfs tenhle problém zmizel. I když se ztratily všechny disky co na té upadlé větvi visely, po restartu se vše normálně našlo. Z toho soudím, že je klíčový scrub. Protože tím donutíš ten FS, aby zkontroloval, jsou-li skutečně všechny kopie k dispozici. Jinak bude držet hubu, dokud na ten datový chunk nesáhneš. Teprve když na něj sáhneš a on ho nenajde, se poohlédne po kopii. Jinak ho přečte ale nové kopie zapíše tam kam může. Což pochopitelně neudělá na disk co mu to neumožní. Ale nejspíš zařve do logu, protože se mu nepodaří smazat tu původní kopii (protože nebude k dispozici).

A s každou další kopií pravděpodobnost, že se mu nepodaří nějakou kopii najít klesá. Pochopitelně je blbost mít 3 disky a zvolit RAID1c3. Vždycky to chce mít v rezervě alespoň tolik místa, aby se ti v případě výpadku největšího blokového zařízení ty data rozložily jinam. A pokud bych měl k dispozici 104 HDD, tak bych se použití Btrfs vůbec nebál, protože to je tak velká kapacita, že si pak můžeš dovolit klidně víc kopií, aniž by tě to zásadně omezovalo.

[PetebLazar]

Roli hot-spare HDD nespatřuji v definované redundanci uložení dat, ale v možnosti tuto redundanci obnovit po výpadku HDD na stejnou úroveň. Proto mne v původním příspěvku překvapilo zmínění pouhých dvou spare pro 104 HDD ZFS konstrukt. Chápu, že odolnost může být teoreticky vyšší než zvolený počet hot-spare, ale stejně bych asi volil počet hot-spare na hodnotu stejnou(vyšší) než je kritický počet.

[Max]

Bohužel jsem se nepochopili, nemluvil jsem o spare. Raději už nebudu nic psát, protože to asi neumím vysvětlit.
Zdar Max

[PetebLazar]

"Tj. se ZFS bych vůbec neviděl problém, kdyby jsi měl poskládaný pool třeba z 13x (8x 8TB hdd RAID-Z2), tj. celkem ze 104 disků a k tomu třeba ještě dva jako online spare."

Těšim se na tuto větu, až v ní tedy bude zmínka o dvou spare.

[PetebLazar]

Představuji si, že autor prvního odkazu patřil k těm co v SANech v 90-tkách osazovali "hnízda" HDD (např. 8+2 RAID6) největších dostupných kapacit (aby se cena za 1TB kapacity dostala na sdělitelné číslo) a takto vzniklý storage rozkrájeli na logické volumy, jež poskytli různým aplikacím s následným podivem na nízkým iops výkonem. Z mého pohledu by se na RAID5+ svazek mělo dívat jako na jeden HDD(SSD) v optimálním případě se shodnou přístupovou dobou (iops) jako nejpomalejší z členů.

[lertimir]

Určitě máš pravdu v situaci, kdy jde o kontinuální zápis většího objemu dat. Otázkou ovšem je, jak se pole bude chovat, když se po něm bude chtít náhodný zápis menších datových objemů (rekordy v DB, zápisy do logů, atd.) Na rozdíl od RAID-0,1,10, pro 4,5,6 musíš i data přečíst, protože zapisuješ méně než strip. A máš obecně dvě možnosti:

1. Přečteš zbylé disky, do kterých se zapisovat nebude a odpovídají místu zápisu, tato data složíš s daty na zápis, spočteš paritu a zapíšeš datový a paritní disk(y)
2. Přečteš datový disk na který se bude psát a paritní disk, spočteš bitovou diferenci mezi původními daty na disku a novými daty (XOR pro 4,5), tuto bitovou diferenci přeneseš do paritního disku(ů) (také XOR pro 4,5) a zapíšeš datový a paritní disk

Z prvního pohledu je možnost 2 problematická, protože na stejném disku čte i píše, ale do hry vstoupí ještě cache v operační paměti. Mnohdy v této situaci pole nemusí nic číst, protože původní data už má v paměti a může provést jen výpočet parity a zápis. A v této chvíli se projeví rozdíl mezi 4 a 5, protože stejný počet IOPSů, které posíláš do všech datových disků, posíláš i do jediného paritního a u 4 je pořád stejný pro celé pole a u 5 je to rozprostřené.

Samozřejmě beru, že použít RAID-4,5 pokud taková zátěž je převažující není rozumné, ale i část zátěže tohoto typu vytvoří diferenci mezi 4 a 5. Nejde o datové objemy, ale o IOPSy.

[PetebLazar]

Dnes má většina storage fyzicky 4KB blok, teoreticky asi může nejmenší alokační block filesystému být N-tym násobkem 4KB (například 16kB pro sesticleny RAID6). Tím lze možná zajistit, že se při jakékoli atomické souborové operaci nad RAID6 budou vždy pouze číst či přepisovat data/parity všech členů. Pravděpodobně vhodnější pro SSD než HDD. Záleží na konkrétním use case (velikost souborů, náhodnost/sekvenčnost IO operací).

[lertimir]

Ano, ale v praxi je to větší oblast. DELL viz:

The best RAID Group write performance can be achieved from the full stripe write. This is the most efficient movement of data from cache to the storage devices. Stripe Capacity is calculated as the number of user drives in RAID multiplied by block size. The default RAID Group stripe block size is 64KB. For RAID 5 (4+1) the stripe size will be 256KB (4*64). If the majority of aligned block size in not 256KB, it would result in striping to the next drive. This is less optimal for high bandwidth, large block random IO.

VMWare

RHEL

Lenovo/IBM

[PetebLazar]

Tady je historický (2013) paper, který se zabýval vlivem velikosti stripe u HDD/SSD-based RAID polí. Šlo tehdy patrně o Intel X25-V Series SSDSA2M040G2GC MLC(2-bit, TLC přišlo až pár let poté), takže asi nebyly v činnosti ovlivněny těmi dnešními hrůzami (pseudoSLC-cache atd). Závěr pro SSD RAID snad tehdy byl, že menší stripe je lepší (z hlediska iops_výkonu/opotřebení).

[lertimir]

Ještě poznámka. Když data posíláš do disku po malých kouscích je to pomalé. Stačí si uvědomit, jak pomalý je třeba zápis do fyzického zařízení příkazem dd, pokud mu nezvedneš "block size" a necháš ho na defaultu 512B (nebo 4kB). A myslím si (a uznávám že tohle je jen spekulace, nejsem RAID designer), že RAID pole neumí/nedělá do disku v atomické operaci větší zápis než strip. Takže když je třeba na RAID-5 se 4 disky zápis souboru 1MB a jsou na něm 64kB stripy, tak ten 1MB rozseká do 16-ti 64kB kousků, dopočte paritu vždy s trojice a pošle tam těch 16 kousků samostatně a příslušné 64kb paritní stripy, i když by teoreticky mohlo spojit 1,4,7,10,13 do jednoho bloku, 2,5,8,11,14 do druhého 3,6,9,12,15 do třetího a poslat je jako jeden a pak dodělat blok 16 (pro něj v každém případě musí dopočíst paritu a přečíst jiné stripy jak jsem psal), ale nedělá to. Pro 4kB stripy by to byla katastrofa.

Velikost stripu je v zásadě balance mezi tím, že zpomalíš zápis velkých souborů, při zmenšení stripu, nebo se vystavíš opakovanému čtení a náročnému zápisu do paritního disku, jak jsem psal předtím, a významnému snížení IOPSů při zápisu malých souborů. A odvíjí se od toho jaký způsob zátěže očekáváš.

[PetebLazar]

Přesně tak.

Tak dlouho jsem ladil parametry RAID5 ze čtyř Samsung 970 Pro (1TB NVMe MLC 2-bit), až jsem to nakonec dal na RAID0. Jsou na to namířeny temporary soubory z Davinci Resolve takže o moc nejde.

K HDD poli RAID6/ZFS/BTRFS (pick your poison) z 8+ členů se chci časem vrátit. Na druhou stran jakkoli se stavba pole z více velkých HDD dnes z hlediska poměru cena/kapacita jeví lákavou, pro náročné sekvenční operace (přehrávání/scubbing) RAW záznamu (bitraty v řádu několika stovek MB/s) může pole se schopností sekvenčního IO 500MB/s+ narazit. Konkrétně v případě kdy na Timeline je v NLE více paralelních streamů (např. záběry z více kamer). Při nutnosti přesunu hlav mezi na disku vzdálenými daty jednotlivých souborů může jít sekvenční výkon rapidně dolu. Řešením může být pole z SSD, ale u něj má poměr cena/kapacita k lákavosti značně daleko.

[lertimir]

Na SSD vůbec nemám názor. Protože tam reálně nevíš, co se děje. Flash čip má rozdílné velikosti pro read block, write block a delete/reset block, zvyšují se v tomto pořadí, a nad tím sedí kontroler, který optimalizuje zápisy a tváří se že jsou to homogenní bloky o menší velikosti než každý z těch bloků a popřípadě ještě ty SLC/MLC cache. Jaké má zápis vlastnosti se zjistí jen experimentálně.

[PetebLazar]

Ty výše zmíněné Samsung 970 Pro 1TB byly posledními comsumer MLC(2-bit) SSD na trhu. Nemají pSLC-cache takže pokud je volný prostor otrimovaný dá se z nich vymáčknout trvalý zápis cca 2500MB/s přes celou kapacitu. Také jejich cena tomu odpovídá, je vyšší než cena těch nejlepších TLC dvojnásobné kapacity.

[lertimir]

A máš nějaký názor na NVMe pro PCI4 jako třeba https://www.alza.cz/kingston-kc3000-nvme-1tb-d6817197.htm? Někdy v letošním roce plánuji udělat upgrade (asi na Ryzen 7000 což umožnuje tyhle disky) a zvažuji co má cenu?

[PetebLazar]

Osobně žádné PCIe 4.0 NVMe nevlastním, takže praktickou zkušenost nemám. Trh dnes obsahuje prakticky jen PCIe 4.0 NVMe, NVMe 3.0 se doprodávají a NVMe 5.0 na trh teprve míří.

Obecně asi lze říci, že NVMe s rychlejšími PCIe a FlashControllery více topí (chladiče bývají doporučené, nebo jsou integrované) a s pokročilejšími výrobními procesy flash pamětí se deklarovaný počet přepisů(životnost) snižuje.

Udávané rychlosti sekvenčního zápisu platí typicky objemy do zaplnění pseudo-SLC cache (nevyužitý prostor TLC buněk kam se data prvotně zapíší v režimu SLC 1bit/cell) a následně v idle uloží do cílových buňek v režimu TLC (3bit/cell). Pokud nárazově zápisy objemově překonají volnou pSLC-cache klesá rychlost zápisu u slušných NVMe do intervalu mezi 1000-2000MB/s. Jednotlivé modely se také mohou lišit průběhem zotavení když toto nastane (do jaké míry se věnuje uvolnění SLC-cache, či případně zapisuje další data přímo v TLC režimu).

Jinak samozřejmě platí asi neustále riziko, že u levnějších modelů s dobrou pověstí (starší recenze/hodnocení) výrobce změní organizaci flash pamětí (např. snížení počtu chipů), což vede k propadu výkonu.

Pozor na to, že Samsung s oblibou označuje své TLC SSD jako MLC (MLC je multilevelcell, takže proč ne) a pouze hlouběji ve specifikacích uvádí, že jde o MLC 3-bit.

Zdaleka bych se vyhnul QLC(PLC) SSD. U nich s nadsázkou řečeno hrozí, že se je za dobu jejich fyzické životnosti ani nepodaří zaplnit (narážka na pokles sustain zápisu do hladiny rychlostí x0MB/s).

Na ten Kingston KC3000 jsem se díval také, v současnosti není cenou od Samsung 9x0 Pro zase tak daleko.

Vypadá to, že u něj (KC3000 2TB) po zaplnění SLC-cache (110s x 7000MB/s) se drží zápis někde okolo 1500MB/s. https://cdn.mos.cms.futurecdn.net/eyzdMmnE38fyrZSGgbPV2U-1200-80.png.webp

Rozdíly v IOPS zase až tak moc neřeším, myslím si že ty jsou již pár let vcelku dostatečné (samozřejmě z pohledu člověka co začínal před 30ti lety na 125MB HDD s latencí 20ms).

Ty Samsung 970 Pro jsem kupoval v průměrné ceně cca 6000Kč/1TB, takže mi všechny TLC přijdou docela laciné.

Obecně bych ani u TLC nešetřil a volil mezi dražšími modely (Samsung 980 Pro, Samsung 990 Pro, WDC SN850, KC30000), vzhledem k očekávané fyzické/morální životnosti rozdíl v cenách není zase tak velký.

Je mi líto, že žádný z výrobců neuvádí model SSD (či umožňuje uživatelsky změnu firmware), který by celé SSD provozoval jen v režimu pseudo-SLC. SSD by při stejných flash pamětech mělo cca 1/3 kapacitu, predikovatelnější zápis a patrně i delší životnost. Řadiče SSD toho prokazatelně schopné jsou (viz zápisy do pseudo-SLC cache).

Tolik k tématu jak si nevybrat SSD.

[PetebLazar]

Výše jsem vytkl Samsungu jeho nakládání s označením MLC (jsou to nakonec všechny 2bit/cell, 3bit/cell, 4bit/cell, ..).

Mezi 4TB NVMe svou cenou září Crucial P3 i jeho P3 Plus vyrianta. To že není použitá technologie uvedena v e-shopu jsem připisoval nedbalosti, ale to že ji neuvádí ani sám výrobce je již trestuhodné. Má jít o QLC, ale v případě že by rozdíl ceny proti TLC byl nižší někdo neznalý se může snadno nachytat.

[Max]

Samsung není jediný, kdo označuje MLC disky původním výkladem. Samsung není jediný, kdo přeznačuje disky za jiné. Crucial se bohužel k podobným věcem v minulosti také uchýlil. Tím chci říci, že vypichovat konkrétní výrobce nedává smysl, různé čachry dělají všichni. Každopádně jediný použitelný ssd od Crucialu je z řady P5 a pro sata je to pak MX500. Osobně jsem testoval P2 řadu a tragédie. P3 na tom bude podobně.
Zdar Max

[PetebLazar]

Co je původní význam MLC? Existovaly zpočátku pouze SLC (1 bit/cell) SSD a následně přisly MLC SSD (2 bits/cell). V době před TLC se nikdy MLC SSD neoznačovaly jako MLC 2-bits/cell. Toto přišlo až s příchodem TLC (viz Samsungove SSD s MLC 3-bits/cell prozrazené až v hlubších specifikacích). Takže bych si troufl tvrdit, že Samsungu používáním označení MLC u TLC nectí původní dlouhodobý význam MLC, ale záměrně tímto značením v kombinaci se nedeklarováním počtu bit/cell zneužívá ve svůj prospěch asociace se starší dražší(robustnější) technologií.

[Max]

Bylo SLC 1bit/cell. Pak přišlo MLC 2bit/cell a zažilo se toto označení pro 2bit/cell (i když MLC znamenalo a znamená 1 < bit/cell). Pak přišlo TLC s 3bit/cell a pak přišlo ono vychytralé označování TLC jako MLC. Definicí to neodporuje, ale proti zažitému označení to odporuje.
Prostě MLC bylo zažito jen pro 2bit/cell a používat toto označení u TLC a QLC je prostě klasická PR podpásovka. V dnešní době na to už moc zkušených lidí neskočí, ale někteří méně zkušení ano.
Zdar Max

[Peter Golis]

A nebolo by z hľadiska rýchlosti vyslobodením používať 8Bit MLC? Predsa len 8Bit je jeden byte.

Len sa pýtam v tomto prechodovom období.

[Max]

To má být nějaký pokus o trolling?
Zdar Max

[Peter Golis]

Ono to tak nejako ajtak pôjde v takých násobkoch až po 4Kbyte. Potom sa tá technológia nahradí niečim iným. Podobne ako sa nahradili klasické rotačáky šindľovým zápisom ktorý už tiež pomaly umiera.

Tak ide život.

[PetebLazar]

Mohlo by to být v muzeu na poličce hned vedle WORM disků (write once/read many) disků pod označením WMRN (write many/read never).

[Peter Golis]

WORM disky?

Poznal som WORM CD/DVD (BR som nepoužíval) a Pásky (plánovaná životnosť pri správnom skladovaní bola 20 rokov), vydržali toho dosť. Občas viac ako mechaniky na ich čítanie. Mali bezkonkurenčný pomer cena/výkon, len boli pre väčšie objemy dát.

[PetebLazar]

Tato zkratka(WORM) pochází s před CD-R éry. Děrná páska, děrný štítek byly WORM.

Myslím, že v případě disků šlo většinou o magnetooptický, či phase-change zápis. https://librarytechnology.org/document/4400 https://www.pcmag.com/encyclopedia/term/pd-disc

[Peter Golis]

Disky WMRN som zažil, jednalo sa o diskety formátu 5'25 alebo 8'. Stačilo sa s nimi previezť v električke/šaline/tramvaji a spoľahlivo sa zničili zapísané dáta. Rozhodilo to stopy.

Na dierne štítky a dochádzkové pichačky som mladý. Ale tie boli tiež dlhodobo skladovateľné, dlhodobejšie ako Orfanikove patenty z Čortóva Hrádu.

Ďalšie typy WORM ako napríklad sklenené optické médiá v caddy boxe som mal len okrajovo, zapisoval na ne kolega. Ale sklo, ak sa nehodí o zem, vydrží večne.

Ja som skôr robil s tými WORM páskami čo mali problém prečítania dát pri audite. Bolo treba niekde v sklade vyhľadať zaprášenú krabicu s mechanikami, nájsť radič a zložiť k nemu prastarý počítač. No, ale obvykle sa podarilo. Raz to bolo humorné, počítač bol ale v danom dátovom centre už nebola zásuvka na 380V. Tak ju museli vyskladať.

[PetebLazar]

Já jsem jsem se s děrnou páskou poprvé potkal asi na střední, byla využita pro nahrávání dat do školního ADT 4300 (patrně již podnikem odstavený kus, ZPA Čakovice by partnerským závodem školy). Koukám, že to se ještě počítačům neříkalo počítače.

[lertimir]

Děrné štítky byly sice WORM, ale při zakopnutí s krabicí od bot plnou štítků se aplikoval nedoceněný příkaz SHUFFLE.