Dotaz: 4 x 16TB disky - aky raid zvolit ?

[Tyler]

Zdravim potreboval by som suvisly storage zo 4 x 16TB diskov aky RAID (iba SW, mdadm) zvolit a aky FS (80 % velke subory nad 800 MB, 20 % male subory od 2 - 10MB ) ?

---

---

Odpovědi

[X]

Chybi zakladni informace k cemu se to uloziste bude pouzivat..

[Tyler]

Zálohy USB diskov, notebookov, fotky, videá

[Kit]

RAID-0 a Ext4.

[Tyler]

no raid0 by som sa práve chcel vyhnúť aspoň 1 disková fault tolerancia by bola fajn ... A s ext4 mám zle skúsenosti pri výpadkoch UPS a naslednej oprave FS ...

[X]

Jasne. Krabice za par tisic co ma ctyri sachty. To muzes rovnou pokracovat tady..

[-nd-]

LVM + Btrfs

[bigBRAMBOR]

Nebude tam lvm zbytecne?

[Harvie.CZ]

Cim vic vrstev tim vic vrstev, aspon budou bodiky za buzzwords

[Heron]

To mas jednoduchy, pokud ti nejde vylozene o vykon, tak R5, pokud by ti o vykon slo, tak R10. Prijdes tim samo o 1/2 disk(y) kapacity. Pokud bys hypoteticky tohle nechtel (coz je velmi rizikovy) tak rozhodne v zadnym pripade ne R0, ale kdyz uz tak jbod.

Ale mozna lepsi varianta nez md je btrfs. Ma to spousty vyhod a nepotrebujes zadny dalsi vrstvy. Dokonce nepotrebujes vyrabet na tech discich ani partysny. A mnoztvi disku ktery obetujes bezpecnosti si muzes vybrat uplne stejne. BTW: A samo v pripade btrfs zapomen na LVM, to je totalni kravina. Zabijes tim naprosto vsechny vyhody btrfs a pridels si spousty starosti a problemu.

---

Dete s tim guuglem dopice!

[pet I.]

To mas jednoduchy, pokud ti nejde vylozene o vykon, tak R5, pokud by ti o vykon slo, tak R10.

Ale mozna lepsi varianta nez md je btrfs.

Má už btrfs stabilni raid5? Já osobně jsem s btrfs šel na raid1, ten stabilní je určitě. A pozor: raid1 v btrfs není mirror (na rozdíl od mdadm).

[Max]

btrfs má raid5 ve stavu, kdy jej lidi používají, zkoušeli simulovat pády atd. a vždy data přežily. Ta implementace není dle wiki na 100%, ale lidi říkají, že to produkčně používají bez problémů. Ale osobně bych do toho asi nešel, bál bych se malého výkonu.

Osobně nevím, zda bych u takto velkých disků šel do mdadm / nějakého pole. Zvážil bych opravdu nasazení btrfs, kterou nějakou toleranci umožňuje a lze z něj v případě velkých hw problémů nějaká data vysekat.
Otázkou jen je, zda nebude vadit CoW overhead, ale pro zálohy by nemusel. Navíc u záloh si chci být jistý konzistencí, což lze s btrfs dosáhnout lehčeji, než s mdadm (u mdadm údajně lze přes dm-integrity).
Zdar Max

[k3dAR]

[...] A pozor: raid1 v btrfs není mirror (na rozdíl od mdadm).

btrfs raid1 neni kompletni mirror (kazdy blok je vzdy jen na 2 discich), ale uz nejakou dobu ma (tazatel musi zjistit zda i v jeho distru) podporu RAID1C4 coz je kazdy blok vzdy na 4discich...

[Andrej]

R5 nad BTRFS provozuju 7+ let. Ten stroj na kterym to bezi za tu dobu byl 10+x natvrdo vypnutej z elektriny a nikdy se nic nestalo. A pozor, raid 1 je JE v btrfs MIRROR. Jen to neznamena, ze jsou vsechna data na dvou konkretnich disich ale znamena to, ze je kazdy BLOK na DVOU discich. A kupodivu, pokud ty disky budou PRAVE DVA, tak se to bude chovat presne jako mirror. Jenze btrfs narozdil od mdadm umi takovyhle pole i pres 3 disky (tzn, kazdy blok je porad na dvou ruznych, ale zvedne to kapacitu).

Coz je mimochodem i mnohem vyhodnejsi z hlediska vykonu. Proc ze to? Protoze klasickej raid netusi nic o usporadani souboru, a prozmenu FS netusi nic o usporadani RAIDu. Zatimco btrfs ti muze ty 4 bloky jednoho souboru rozlozit na 4 disky, takze jak pri zapisu tak pri cteni ziskas nasobky vykonu.

Btrfs umi i 3/4 (pripadne vice, pokud vim nekdo zkousel 8) nasobny kopie, ale to je pro naprosto drtivou vetsinu ucelu kravinium.

Mimochodem, klasicky raidy uz nenajdes ani v diskovych polich za miliony. Protoze to ma spousty nevyhod. Jako ze treba kdyz chces pridat kapacitu, tak musis pridat trebas 5 disku nejmin (pripadne nasobky) ... takze tu mam trebas policko od EMC, ktery se chova (a mozna tam i je, nezkoumal sem) prakticky stejne jako btrfs. Proste pridas disk, das expand a hotovo. Stejne tak to uz nema zadny raidgrupy a podobny hovadarny, proste reknes, ze volume ma byt R5/6/... a on to nejak prepocita, muzes to pak kdykoli zmenit (samo v ramci dostupny kapacity).

---

Dete s tim guuglem dopice!

[pet I.]

A pozor, raid 1 je JE v btrfs MIRROR.

Není

Jen to neznamena, ze jsou vsechna data na dvou konkretnich disich ale znamena to, ze je kazdy BLOK na DVOU discich. A kupodivu, pokud ty disky budou PRAVE DVA, tak se to bude chovat presne jako mirror.

MIRROR je zrcadlo - zrcadlí jeden disk na druhý. A pak, když se poškodí oba disky zároveň (např. náhlá potopa v serverovně), je možné vzít část dat z jednoho disku a díry zaplnit daty z druhého pouze podle polohy na disku (offsetu).

A RAID 1 v BTRFS pouze garantuje umístění (někde) na dvou discích, ale už nepoužije na obou stejnou pozici. Neříkám, že je to špatně, prostě to tak je.

[Andrej]

A pak, když se poškodí oba disky zároveň (např. náhlá potopa v serverovně), je možné vzít část dat z jednoho disku a díry zaplnit daty z druhého pouze podle polohy na disku (offsetu).

A přesně totéž lze udělat také s Btrfs RAID1, jenom ne podle offsetu, nýbrž (jak je u Btrfs a ZFS obvyklé) mnohem lépe, flexibilněji, bezpečněji a (navíc ještě většinou) automaticky.

Jak bude u AID1 bez R zaručeno, že data, která jsou na stejném offsetu(*), jsou nepoškozená a shodná s druhou, poškozenou replikou? Když se repliky na obsahu bloku neshodnou, která má pravdu?

(*) …což je zbytečné a suboptimální, ale nic naplat, primitivní AID metadata nic lepšího určit neumí…

Btrfs dovede určit (s pravděpodobností hraničící s jistotou == 1 − pravděpodobnost kolize checksumu), které bloky se podařilo obnovit (tedy existuje alespoň jedna replika s platným checksumem) a které jsou nenávratně pryč.

AID bez R se svým (zbytečně) přesným mirrorováním tohle^^^ neumí a klidně vypustí do světa náhodná data — jenom proto, že se zrovna dají „přečíst“. Fujble.

Neříkám, že je to špatně, prostě to tak je.

Prostě to tak je a je to tak dobře.

[xxl]

A RAID 1 v BTRFS pouze garantuje umístění (někde) na dvou discích, ale už nepoužije na obou stejnou pozici. Neříkám, že je to špatně, prostě to tak je.

Mně je tedy celkem fuk, jak si to filesystém ukládá. Důležité je, že dodává správná data.

[j]

Prosimte neblabol o vecech, kterym zjevne zcela nerozumis.

R1 neboli tzv zrcadlo je definovany tak, ze kazdy sektor disku se zreplikuje na dalsi disk a konfiguraci je receno na ktery konkretne. NIKDE neni receno, ze ty sektory budou na stejnych mistech a ani byt NEMUZOU. Protoze na tom druhym disku muze byt nektery z nich trvale klidne uz z vyroby oznacen jako vadny.

Mimo jiny PRESNE tohle je duvod, proc potrebujes dost casto exaktne stejny radic, pokud ti ten puvodni chcipne, protoze to KAZDY dela JINAK.

A uz vubec neblabol o tom, jak budes zachranovat data ze dvou vadnych disku, to jen ukazuje na to, ze vubec nechapes, k cemu je zcela libovolnej raid. Raid NENI zaloha !!! A nejen to, ty naprosto nechapes, jak raidy (ne)funguji ... libovolnej raid v ramci svych vlastnosti zajistuje, ze data budou k dispozici, pokud je lze precist. Takze pokud bude na R5 vadna 1/3 kazdyho ze 3 disku, pricemz ty vady nebudou mit prunik, tak ten raid BUDE citelny. Uplne stejne to plati pro R1 a 1/2 ze 2 disku. To je zazrak co?

A PRESNE stejne to plati pro libovolnej BTRFS raid ... ovsem s tim, ze pokud je dost disku (a mista), tak btrfs umi (narozdil od md) zajistit to, ze dokud je k dispozici N+1/2/... disku volnyho prostoru, tak je raid porad plne funkcni a neni degradovany. Jednoduse proto, ze umi chybejici data zreplikovat na dalsi volne funkcni disky, coz zadny klasicky raid takhle neumi a ani umet nemuze. Jednoduse proto, ze nevi, kde data jsou a kde ne.

Vubec neni pravda, ze by raid neslo cist, pokud se objevi nejaka vada na druhym/tretim/... dalsim disku. Jen te typicky kazdy svepravny HW i SW posle dopice s libovolnym zapisem. A znova NIKDO svepravny to stejne NIKDY resit nebude, protoze pokud chcipne druhej disk, obnovi se zaloha. Nikdo nebude travit dny nebo tydny skladanim dat.

Mimochodem, prave md ma presne jak andrej naznacil naprosto zasadni vadu na krase - specielne prave v pripade R1 nelze nijak rict, ktery data jsou ty spatny a ktery ty spravny. A presne timhle zpusobem rozjebanych raidu sem osobne videl nekolik, pricemz HW jako takovej zadnou zavadu nemel, bylo to rozjebany ciste SW cestou. Staci na to bohate, kdyz stroj natvrdo lehne v okamziku zapisu, a jeden disk je o fous rychlejsi. A co zjevne taky nevis, tak presne z tohodle duvodu maji HW radice baterku.

---

Dete s tim guuglem dopice!

[pet I.]

Mno, asi tomu rozumíš více, když i víš, o čem co vím

R1 neboli tzv zrcadlo

RAID 1 je definován tak, jak popisuješ. Ale často (viz mdadm) je realizován jako MIRROR, to je 1:1, což je poněkud přísnější definice než RAID 1. A ano, MIRROR není oficiální název realizace 1:1 a často se používá i pro "ne 1:1" RAID 1.

R1 neboli tzv zrcadlo je definovany tak, ze kazdy sektor disku se zreplikuje na dalsi disk a konfiguraci je receno na ktery konkretne. NIKDE neni receno, ze ty sektory budou na stejnych mistech a ani byt NEMUZOU. Protoze na tom druhym disku muze byt nektery z nich trvale klidne uz z vyroby oznacen jako vadny.

To hovoris o logickem nebo fyzickem layoutu disku. Ty hardchyby totiz maskuje firmware v disku a na logickem layoutu, se kterym pracuje pocitac, se neprojeví. A pokud je tam už hardchyb tolik, že se maskovat nedají, tak bych tomu už data nesvěřoval.

A uz vubec neblabol o tom, jak budes zachranovat data ze dvou vadnych disku, to jen ukazuje na to, ze vubec nechapes, k cemu je zcela libovolnej raid. Raid NENI zaloha !!!

Chápu, to že zákazníkovi plaval výcvikáč - cca 1 m bahnité vody která zaplavila servery i archivní diskety a my mu nakonec data vytáhli výše popsaným postupem ze skřípějících umírajících HDD pomocí ddrescue není podle tebe pravda.

PS: Asi 5 let jsem pracoval přímo ve vývoji HDD, takže o nich něco vím.

[Zoufalec]

To mas jednoduchy, pokud ti nejde vylozene o vykon, tak R5, [...]

Pozor, u takto velkých disků zkontrolovat Unrecoverable Read Error!

[Zoufalec]

Asi jsem se opět unáhlil... :-/

[MP]

Obvykle zfs nedoporucuji (nebot to nepouzivam), ale nebylo by to lepsi nez to btrfs v tomto pripade?

[Harvie.CZ]

ZFS je aspon trochu otestovany. Btrfs mi prijde jako minovy pole. Na wiki maj tabulku unstable vlastnosti btrfs, ktery nesmi clovek pouzivat kdyz nechce prijit o data Takze stable to je jen castecne a clovek musi bejt furt ve strehu.

[lertimir]

No to je naprostý nesmysl, který se táhne tak 12 let. Jediná skutečně nestabilní záležitost v BTRFS je problém v RAID56 v případě nekorektního ukončení (Výpadek napájení, pověšení jádra), pak data která jsou "rozpracovaná" mají nekorektní checksum a přijde se o ně. Nicméně s UPS a serverovou instalací, kde nejede spousta nesmyslných programů to nemusí být problém. Používám btrfs už asi 10 let, když jsem ho použil na své první SSD jako jediný systém, který bere SSD na vědomí. A cca 7 let úplně na všem. Nikdy žádný problém se ztrátou dat, naopak několikrát mě data zachránil, když začal hlásit problém, když byl špinavý kabel a chyby mezi diskem a MB nebo když disk pomalu odcházel do magnetického nebe. Včetně mnohých pověšení jak notebooku tak stanice a několika výpadků proudu. A to co používám je bud raid 1 na 5 discích, raid 10 na čtyřech stejných a single drive (z čehož jeden single drive je nad jedním starým MDRAID 5 nad 4 disky a také pomohl, když nesedly checksumy, btrfs hlásil chyby a následně jsem našel padající disk mezi těmi 4) ZFS nepoužívám, ale když jsem se o něj zajímal, tak pořád běžel v userspace a tam jsou vždy silné nároky na procesor na přepínání kontextů, možná že ho už do jádra pustili.

[trekker.dk]

Jediná skutečně nestabilní záležitost v BTRFS je problém v RAID56 v případě nekorektního ukončení (Výpadek napájení, pověšení jádra), pak data která jsou "rozpracovaná" mají nekorektní checksum a přijde se o ně. Nicméně s UPS a serverovou instalací, kde nejede spousta nesmyslných programů to nemusí být problém.

A u ZFS na stroji, kde jede spousta nesmyslných programů a UPS nemá, protože uživatel to první chce a za to druhé utrácet nechce, je to jak?

[lertimir]

No pokud primární zájem je mít systém, který nepoškodí data při náhodném výpadku napájení, tak skutečně btrfs RAID56 není správně.

[xicht]

Sel bych do ZFS (Striped Mirror aka RAID10).

[czjaromir]

Určitě softwarový raid. Co mám zkušenost s HW raidem, když klekne řadič, shání se pak stejný čipset. R5 by nejspíš stačilo. Jen si tak nastavit ještě hlášení, třeba email když vypadne disk. Protože pak na to člověk může přijít až odejdou dva t.j. když raid přestane dávat, a to je fatální pro data.

[Kit]

Pikantní je, když odejdou různé chunky na různých discích. Rekonstrukce je pak docela zábavná.

[rpajik]

Tohle už dávno není pravda.

Hodně vendorů používá standardizovaný formát metadat DDF, Intel pak má svůj Matrix Storage. Obojí dnes spolehlivě přečte i mdraid -> vezmu disky z mrtvého řadiče, dám jako JBOD do nějakého linuxového boxu a mdraid velmi pravděpodobně sestaví pole.

Spíše je otázka, v jakých situacích má HW RAID smysl.

[dustin]

Dozvíš se ale dopředu, že zrovna daný HW raid tak bude fungovat? Jde o mdraid nebo dmraid?

[Harvie.CZ]

Kdyz mate mirror na klasickym mdraidu a jeden disk se poskodi, tak se za platna data povazuji ty z toho disku, ktery ZROVNA JDE PRECIST. Kdyz je raid postaveny na ZFS, tak filesystem primo vidi na oba disky a dokaze z nich vybrat KOREKTNI KOPII, kde sedi checksumy. Stejne checksumy na ZFS ochrani data i pred vyhnivanim bitu (cosmic bit flip), proti tomu mdraid nepomuze.

Nevyhodou je horsi vykon ZFS proti EXT4, vyhodou je pak velmi pouzitelna transparentni komprese, kterou se vetsinou aspon 5% disku usetri.

[jiwopene]

Nevím jak na tom je btrfs s RAIDem. Zvolil bych ZFS s zraid1 (nebo vyšší). Při zraid1 je použitelná kapacita, nepletu-li se kolem 48 TB.

[Tyler]

44 TB a ano pouzil sa FreeNAS + raidz-1

[Josef Kufner]

BTRFS funguje dobře, pokud má redundanci a může ji používat pro opravy. Je dobré si hlídat volné místo a mít vždy možnost jeden disk odebrat, nebo mít volný konektor pro připojení nového disku.

Na zálohování velice doporučuji navyrábět subvolumes pro jednotlivé zálohované věci a používat snapshoty.

[Leeny]

Ani sa neprihlasujem. Ako bolo napísané potrebuješ tie disky aby boli aktívne súvislé, u mna je to tak ze mam par terabytove disky a tie pripojím raz za cas a zalohujem vsetko co sa da, filmy fotky atd len by ma zaujimalo tu na od ludi ci sa na taketo veci prave nehodí XFS. A este sa tu nikto v diskusii nezmienil o hammerfs co ma dragonflybsd ale jasne diskusiabje o linuxe len take ripnutie.

[Peter Golis]

A este sa tu nikto v diskusii nezmienil o hammerfs co ma dragonflybsd

Tak si prvý. Je to jeden z FS ktorý má checksumming aj na dáta a má aj dostupné zdrojáky, takže je fajn.

[Kit]

Od doby, kdy jsem po výpadku napájení přišel o data v otevřených souborech a ještě mi bylo předkládáno, že je to tak správně, XFS ke mně nesmí.

[GeorgeWH]

Ale ved to je pravda a o XFS davno zname. Proste to nema rado vypadky natvrdo. Preto musis mat UPS.

[Max]

Z toho důvodu jsem ho nikdy nepoužíval / nechtěl. Jen by mě zajímalo, zda to je stále aktuální problém, nebo to jsou už pohrobky minulosti. Přecijen, RHEL do XFS za posledních x let nalil hodně vývoje.
Zdar Max

[Heron]

Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1.

Od roku ~2012 je xfs zcela nový fs.

[Heron]

Ještě odkaz (xfs.org mi aktuálně neběží).

[Max]

Já jsem ho teď začal používat, jelikož je to doporučený FS pro Minio S3 storage, který jsem rozjel a začínám si s ním hrát. Takže co mám čekat a nečekat. Vím jen, že je tam dost bouřlivých změn a RHEL do něj sype spoustu věcí., asi mj. i kvůli Stratis.
Každopádně zkazky o problémech s daty v případě nějakých nečekaných událostí jsem slyšel i pár let zpátky, takže proto jsem se ptal spíše na aktuální stav, než co bylo v roce 2007.
Zdar Max

[Heron]

Každopádně zkazky o problémech s daty v případě nějakých nečekaných událostí jsem slyšel i pár let zpátky, takže proto jsem se ptal spíše na aktuální stav, než co bylo v roce 2007.

Jenže ty zkazky je potřeba analyzovat jednu po druhé.

Při hledání tohoto problému (z roku 2007) jsem narazil též na "problém" kolem roku 2012, který se ale týkal všech FS (včetně tehdy nového ext4) a který se týkal zmizení dat po přejmenování souboru a následném pádu systému (nebo výpadku napájení).

Podstatné je, že tento "problém" se týkal všech vs kromě jednoho velmi speciálního případu ext3 s ordered journal. Kde to fungovalo více méně náhodou. A někteří se s tím nesmířili dodnes (s tím, že by měli postupovat dle specifikace a nikoliv pocitů).

Každopádně, já používám XFS dlouhodobě (i před rokem 2012) jako druhý FS do páru s BTRFS. Tam, kde nepotřebuju btrfs nebo se vyloženě nehodí (např pro provoz postgresql), nasazuju jedině xfs.

Výhody jsou:

Velmi rychlé vytváření (proti ext3, ext4 z počátku také velmi pomalé, postupem času tam dali různé lazy volby) - protože si tabulky vytváří (a maže) automaticky dle potřeby.

S tím souvisí i optimalizace adresáře, když do ext4 adresáře naliju miliony souborů, tak adresářový záznam naroste (přirozeně) a když ty soubory smažu, tak zůstane velký (i když je v něm pouze jeden soubor) a jeho otevření trvá dlouho. Toto lze vyřešit jedině přes fsck.ext4 -D (tedy s odstávkou).

Velmi rychlé zvětšení svazku (souvisí s předchozím).

Intenzivně používám LVM (tam, kde nelze použít BTRFS), vytvářím a rozšiřuju svazky a nechce se mi čekat.

Rychlé mazání velkých souborů. Dříve (zejména na ext3) mazání stovkyGB velkého souboru trvalo klidně i několik minut. Pokud to má člověk jako storage pro zálohy nebo image disků, tak je to celkem otravné.

xfs_fsr - "defragmentace". Co si budeme vysvětlovat, v blokovém světě a na používaném oddílu nelze dosáhnout vždy perfektně souvislých souborů, takže tento nástroj se hodí. "Stárnutí" jiných FS po letech lze pozorovat (a to i na ZFS) a není to moc hezké. Proto používám XFS a BTRFS, oba mají nástroje pro úklid.

Jedinou nevýhodou, kterou to má, je nemožnost zmenšení fs. Toto jsem nenašel ani v projektové dokumentaci pro statis, ale tam to "řeší" tak, že všechno je masivně thin provisioned, takže po smazání dat je místo dostupné. (Tedy to, co btrfs řeší levou zadní od roku 2010 a navíc btrfs má online shrink, kdyby bylo potřeba zmenšit device.)

[trekker.dk]

Toto jsem nenašel ani v projektové dokumentaci pro statis, ale tam to "řeší" tak, že všechno je masivně thin provisioned

Tohle na rotačních discích to musí být naprostý zabiják...

[Heron]

To musí, ale tam asi stratis nemíří (vzhledem ke stále budoucímu datu vydání). Mají tam podporu i pro cache devices. A nějaký tiering.

[GeorgeWH]

filmy fotky atd len by ma zaujimalo tu na od ludi ci sa na taketo veci prave nehodí XFS.

XFS je vhodne pre velke subory, takze asi aj hej. Ale urcite sa nehodi napr. pre maily, kde mazanie niekolkych 100 mailov z niekolkych 1000 trvalo desiatky sekund. Z ext3 to uz bolo ok.

[Heron]

Ale urcite sa nehodi napr. pre maily, kde mazanie niekolkych 100 mailov z niekolkych 1000 trvalo desiatky sekund. Z ext3 to uz bolo ok.

Od optimalizace v roce 2012 se hodí i pro velmi mnoho souborů (má tam testy pro 25M souborů per thread). Pokud se ti to zadýchávalo při mazání stovek souborů, tak bylo špatně něco jiného.

[GeorgeWH]

Tak podla etckeeper-a som to migroval 6 Nov 2014, ale to bol este asi Debian Squeeze, tak tam to este asi nebolo. Server mi do dnes bezi, je to stara sunka ProLiant ML110 G5.

[Max]

Takže já jdu do toho. Už mám na cestě za dobrou cenu 3x 6TB Toschiba MG04. Za tu cenu člověk dostane bezkonkurenční výkon. Jsou na úrovni WD RE4 / Gold disků. Jen jsou tedy hlučnější, ale u mě jdou do serveru ve sklepě, takže mě to netrápí.
Budu tedy migrovat domácí úložiště ze 4x 2TB RAID5 (nad tím BTRFS) na 3x BTRFS RAID1 se dvěma daotvými replikami a třemi metadatovými replikami s tím, že budoucna budu dokupovat další disky. Mám to jako standalone úložiště, jehož vytížení je 90% času v idle (to i vysvětluje, proč přežívají v tom RAID5 disky jako WD Green :D).
Zdar Max