Dotaz: RAID 4 bez strippingu

[Martin Gašparík]

Ahoj.

Chcel by som na Linuxe vytvoriť SW RAID 4 tak, aby sa bloky dát zapisovali lineárne na disk (podobne ako pri dm-linear) a nie ako pri RAID 0. Cieľom je rozdeliť pole na viac partícii tak, aby každá partícia bola pravé na jednom fyzickom disku a nebola prekladaná cez viacero diskov. Potom by sa dali, v prípade že v poli odíde dva a viac diskov, zachrániť aspoň niektoré dáta.

Je to vôbec možne? Dik

---

---

Odpovědi

[Filip Jirsák]

První věta vypadá, jako byste chtěl RAID5. Toho druhého požadavku (aby oddíly na RAIDu vycházely právě na jednotlivé disky) na obecném RAIDu nedocílíte, protože vrstvy nad RAIDem nevědí, co je pod ním. Možná by něčeho takového šlo dosáhnout s RAIDem integrovaným v souborovém systému – např. btrfs nebo ZFS. Ale i tak si myslím, že by to byla zbytečná práce navíc – když vám odejdou dva disky, tak obnovíte to, co půjde ze zbylých disků přečíst. RAID stejně pracuje na úrovni bloků a ne souborů, a skládání souborů do bloků není u moderních souborových systémů úplně přímočaré. Takže když se použije stripping, ještě to neznamená, že budete mít každý soubor nasekaný na všechny disky.

Stejně ta data musíte mít někde zálohovaná. To, že se u RAIDu počítá s odolností proti výpadku n disků není proto, že byste při výpadku většího počtu disků zachraňoval data (v takovém případě je budete obnovovat ze zálohy), ale abyste při výpadku disku měl čas na jeho výměnu.

[Sten]

Tohle dělá unRAID. Jednotlivé disky se chovají jako samostatné disky, mají vlastní souborový systém, a unRAID z nich počítá paritní disk. unRAID je celý operační systém, nebude to fungovat na Linuxu, nicméně lze v něm spustit Docker, ve kterém už Linux být může.

[Martin Gašparík]

Nebo ještě lépe: http://www.snapraid.it/

[Martin Gašparík]

Ďakujem všetkým. Ten snapraid vyzerá zo všetkých riešení najlepšie. Navyše to uchováva aj hashe súborov, takže nemusím integritu kontrolovať inými spôsobmi. Plánujem to použiť iba na dáta, ktoré niesu až tak dôležité a vzhľadom ta to, že je ich pomerne dosť, tak riadne zálohovanie nepripadá v úvahu. Ide v podstate o archív, takže ani dlha doba obnovy nie je až taky problém. Vždy to bude lepšie ako nič. Už parkrát s mi stalo, že disky začali postupne vykazovať vadne sektory, takže po nakopírovaní na novy disk som o par súborov prišiel. Paritný disk by mohol vyriešiť aspoň tento problém.

[Petr]

Neni levnejsi koupit dalsi disk a mit treba standardni raid6? Obnova souboru z bloku rozsypanych na ruznych discich bude daleko drazsi.

[-]

na toto uplne staci LVM

[lertimir]

Tento požadavek je velmi zvláštní. Zaprvé RAID 4 není o stripingu, Je o tom, že jako paritní disk se používá v celém prostoru jen jeden disk. Ale vůbec to neznamená, že data na zbylých discích nejsou stripována. Primárně RAID 4 znamená. že veškerá zátěž zápisu v celém datovém prostoru se koncentruje do jednoho jediného disku toho jediného disku. (což znamená, že by odešel nejdříve.)

Nedají se ulovit dva zající. (náklady na uložení bez záloh a současně rozumná bezpečnost.) Navíc časové náklady při restauraci dat z rozpadajících se polí nebo rozpadlého disku jsou enormní. Pred pár lety jsem po zjištění že disk mi vykazuje nějakou chybu restauroval ddrescue 3TB disk do nového volného disku a kontinuální běh restaurování byl 6 dní. ale byla to situace kdy mne proces moc nezatěžoval. V desktopu se prostě točily dva disky, kterých jsem se v té době nedotýkal.

Podle mne primárně důležité si důležitost a cennost dat vystrukturovat. Moje strukturace je taková, že mám unikátní (velmi osobní) data, které mám minimálně na třech úložistích, z toho jedno je raid pole a jedno úložitě je mimo domov pro případ katastrofy jako požár. Důležitá data - dvě úložiště z toho jeden RAID. Nahraditelná data - typicky stažená z netu, povětšině na jediném disku, kromě malé části, kterou mám rád a tu mám nakopírovou na dvou discích, čistě proto, abych když by disk padl nemusel tyhle data znovu hledat a stahovat.

Při ceně současných disků ve srovnání s osobní cenou těch dat jsou to pro mne přijatelné náklady.