Vlákno názorů k článku
Btrfs bude varovat při vytváření a konvertování RAID5/6 od Lukáš Turek - Nebylo by jednodušší ten RAID 5/6 opravit, než...

Miroslav Šilhavý: Experimentální neznamená, že přijdete o data. A zrovna k btrfs RAIDu moc alternativ není – btrfs RAID na rozdíl od alternativ může fungovat s libovolným množstvím různě velkých disků.

Ona je pak otázka kdo vlastně potřebuje btrfs RAID5/6. Já když si před pár lety zřizoval domácí úložiště, tak jsem původně uvažoval o mdraid RAID5, ale nakonec skončil u btrfs RAID1 (původně dva disky, dneska už pět). S přihlédnutí k cenám disků mi RAID5 přestal dávat smysl, resp. nestojí to za ty potenciální problémy.

@Filip Jirsák

Zrovna libovolné množství libovolně velkých disků je dost diskutabilní výhoda. Pro RAID to představuje velmi složitou logiku a potřebu relokovat data při změně geometrie. S sebou to přináší potřebu mít velmi složité diagnostické nástroje, protože při problému musíte vědět, co zrovna RAID dělal, dělá a chystá se dělat; při tradičních geometriích se to ještě jakž takž dá usledovat, ale u Btrfs jen složitě.

Změnu geometrie pole potřebují podniky víceméně jen při migracích a upgradech dat. Za běhu je to dost nepotřebná funkce, která se dá nahradit jinými postupy, které jsou přímočařejší a ovladatelnější a s předpokladatelnou náročností. Potřebujete to jednou za dlouhý čas, ale když ten čas nastane, potřebujete aby to proběhlo předpokladatelně a spolehlivě. To vede právě k tomu, že to není atraktivní funkce, aby to uživatelé moc testovali.

Co by naopak uživatelé, malí i velcí ocenili, by byl multi tiering. Tam si dovedu představit, že by atraktivita a chuť k testování byla velká.

Zrovna libovolné množství libovolně velkých disků je podstatná výhoda, protože tak můžete vytvářet pole z levných disků, které prostě už máte a jinak by se nepoužily. Logika za tím mi nepřipadá moc složitá. Relokovat data při změně geometrie právě nemusíte. Stejně tak nemusíte nijak extra sledovat, co RAID dělal nebo dělá – díky CoW jsou data buď na původním místě nebo na nové místě.

Jediné, co je kontraintuitivní, je to, že i pro pole z levných disků „co dům dal“ potřebujete UPS (když chcete používat RAID5/6). Na jednu stranu je to logické, každé úložiště by mělo mít UPS, ale chápu, že ne každému to dojde. Ale třeba u XFS, které mělo stejný problém (i bez RAIDu) při výpadku napájení, se UPS považovala za standard.

Relokovat data při změně geometrie právě nemusíte.

Ale jo, v obecném případě musíte, jinak budete mít nerovnoměrné rozložení dat, s tím spojené nestejné opotřebovávání a kolísavý výkon. Zrovna výkon potřebujete mít předpokladatelný a pokud možno i ustálený. Obvykle se víc hodí ustálený nižší výkon, než rozkolísaný vyšší - už je kvůli tomu, že pak těžko odladíte výkon celé aplikace, když jsou všechny parametry proměnlivé.

Stejně tak nemusíte nijak extra sledovat, co RAID dělal nebo dělá – díky CoW jsou data buď na původním místě nebo na nové místě.

Za běžného provozu máte pravdu. Ve chvíli, kdy hledáte problém, potřebujete nejprve vědět, co se událo, lokalizovat, na čem se problém projevil a proč se daná operace prováděla. Náročnost takové diagnostiky roste se složitostí, a pokud má být v tomto ohledu Btrfs použitelné, musí poskytovat diagnostické informace uspořádané tak, aby k něčemu byly.

Jediné, co je kontraintuitivní, je to, že i pro pole z levných disků „co dům dal“ potřebujete UPS (když chcete používat RAID5/6).

"Co dům dal" bych moc nepředpokládal. Možná tak na hraní pro nadšence. V běžném desktopovém použití se RAID 5/6 nevyužívá, zejména kvůli hluku a teplu. Na to je use case opravdu jen okrajový.

Daleko zajímavější to může být pro datová centra, ale tam zas není takový problém zavést určitá pravidla pro výměnu modelu za model, kapacity za kapacitu. Bude Vám k ničemu, že filesystem funguje spolehlivě, když mu např. poklesne dramaticky výkon nebo začne lagovat - a zároveň nemáte k dispozici ani nástroje na zjištění příčiny.

RAID 5/6 pro Btrfs má podle mě smysl jedině s gradací do enterprise segmentu, SOHO uživatelé se nebudou nijak mocně účastnit vývoje (a tudíž to bude dál stagnovat).

Miroslav Šilhavý: My se tu ovšem bavíme o poli, které slouží třeba jako odkladiště souborů v SOHO nebo nebo ve firmě, která má na důležité věci pořádné pole. Takže to vaše nestejné opotřebování nebo kolísavý výkon jsou záležitosti z úplně jiného světa.

Když se podíváte na běžné uživatele linuxu na desktopu, ti se neúčastní vývoje ani btrfs, ani ničeho jiného. Když se ale podíváte z druhé strany na vývojáře jádra, spousta z nich má doma nejspíš nějaký servřík, nejspíš se jim doma také povalují různé disky – takže je ideální domácí úložiště na videa a fotky postavit právě z toho, než kupovat nové disky a stavět z nich profi hardwarový RAID s garantovaným výkonem.

Mimochodem, to, že je nějaká technologie experimentální, neznamená, že ji budou používat jen lidé, kteří ji vyvíjejí. Zrovna u souborového systému má pro vývoj význam i taková „drobnost“, jako že ten systém nachodil tisíce hodin v nejrůznějších konfiguracích, a ověřilo se, že tam nejsou nějaké chyby v ošetření okrajových případů (resp. když tam takové chyby jsou, přijde se díky tomu na ně a opraví se).

@Filip Jirsák

Já Vám rozumím, ale kroutím hlavou nad tím, že by někdo opravdu potřeboval RAID 5/6 (tj. pole pro výkon a redundanci informací) a zároveň to skládal z odpadu. To nedává žádný pořádný smysl, protože nezískáte ani výkon, ani dobré bezpečí dat. Zůstane Vám přínos RAID 5/6 je oproti jednoduchým RAID 1/10 jen ve vyšší využitelné kapacitě, a to není zas tak zásadní faktor.

Proto si myslím, že je to tak málo používané a nedoladěné.

RAID5/6 není pole pro výkon, ale pole, které s minimálními náklady zajistí odolnost proti výpadku jednoho/dvou disků (v případě btrfs). Vyšší využitelná kapacita je pro tahle nekritická využití zásadní faktor – na NASu pro uložení fotek nebo videí nikoho nezajímá, jestli se bude něco načítat o milisekundy déle. Jediné, co každého zajímá, je to, jestli bude muset kupovat další disk, aby tam mohl nahrát fotky z další dovolené.

Ve vysledku to nebude nic jineho nez variace na Intel matrix storage, aka: rozdelime disky podle velikosti na partisny, nad tim udelame RAID5/6. Tim, ze konce disku uz jsou jen na nekterych, tak se tam meni pocet devicu v poli. Nad tou sadou raidu pak jde udelat md/dm/lvm a pospojovat to. Dostavate kapacitu X.

Btrfs imho udela preste tohle same, jen ne po partisnach ale po svych alokacnich jednotkach, a vysledek bude kapacita stejna, tj. X.

Pokud disky nemenite - je i staticka konfigurace dobra. Pokud je menite, tak je tam male plus, ze btrfs to umi rebalancovat za chodu lepe.

RDa: btrfs ukládá data po blocích a různé RAIDy řeší tak, aby bloky byly uložené redundantně. Tj. v případě RAID1 aby každý blok byl na dvou různých zařízeních apod. Neexistuje tam tedy nic jako „(přebývající) konce disků“. Dělat to ručně pomocí malých partition a jejich spojování pomocí md/dm/lvm můžete, ale nemyslím si, že by to bylo reálné a udržitelné.

A kdyz zaplnite N* kapacitu nejmensiho disku, tak mate na BTRFS pak jaky stav? Prece zaplnene vsechno vespod, a nahoru trci prebyvajici konce disku.

Je to stejny princip jako v (md) Raid0 pro nestejne velike disky - automaticky se to rozdeli na segmenty a ty se individualne prolnou.

Nebo nam vysvetlete jak si predstavujete ukladat data na nestejne velike disky, kdyz vyzadujete odolnost pro +1 nebo +2 selhani (raid5/6)

@RDa

V tom je právě to kouzlo. Redundanci lze zajistit i v těch přebytcích - jen data už nejsou např. na čtyřech discích, ale jen na třech, dvou (mirror). Proto Btrfs nezajišťuje, že se jedná o RAID 5 nebo RAID 6, ale jen ten faktor redundance

Si protirecite clovece:

Neexistuje tam tedy nic jako „(přebývající) konce disků“.
vs.
jen data už nejsou např. na čtyřech discích, ale jen na třech

Presne tohle jsem myslel. I ty prebyvajici konce jdou pouzit (a bud si to udelate sami, nebo to za vas udela fs - btrfs/zfs/reiser5? vsechno tohle integruje ty veci patrici spis do LVM prave z toho duvodu.. at s tim clovek nemusi soupat rucne).

Btw u BTRFS se nejspis nedistribuuji primo bloky po jednom ale ta datova alokacni jednotka (cca 8-16GB?), ktera bude zraidovana v celku - tudiz je to hodne podobny tomu pristupu kdyz si to rozpartisnujete, zraidujete, a zpetne spojite.

Takto nějak vypadá částečně plné RAID1 pole z disků 6+8+14 TB :

btrfs filesystem show
Label: 'toshiba8TB' uuid: xxx
Total devices 3 FS bytes used 5.06TiB
devid 1 size 7.28TiB used 3.44TiB path /dev/xxxc
devid 2 size 5.46TiB used 1.62TiB path /dev/xxxb
devid 3 size 12.73TiB used 5.06TiB path /dev/xxxd

Jak je viděl, plní to všechny disky proporciálně stejně, takže nejsou žádné "konce".

RDa: btrfs ukládá data po blocích a pokud vím nezaplňuje disk bloky od začátku. Takže asi nenastane ten případ, že by disky byly zaplněné od začátku a trčily by tam konce disku. V RAID5 je to tak, že se vezmou bloky z různých disků, z nich se spočítá parita a blok se uloží na další disk.

EDIT: komentář beru zpět, napsal jsem nesouvisející nesmysl. Musím říct, že ta vlákna tady na Rootu jsou opravdu nepřehledná.

9. 3. 2021, 18:38 editováno autorem komentáře