Nebylo by jednodušší ten RAID 5/6 opravit, než přidávat další varování?
Ne, nebylo by to jednodušší.
Navíc nejde o jednu vlastnost, ale o to, že režim RAID5/6 je u btrfs stále považován za experimentální. Jinak by samozřejmě stačilo tuhle vlastnost prohlásit za zdokumentované správné chování btrfs. Jiné souborové systémy s v podobných extrémních situacích také nechovají hezky, ale je to známé a zdokumentované chování a nikdo kvůli tomu nepovažuje příslušný souborový systém za nestabilní. Ale vývojáři btrfs chtějí, aby byla RAID5/6 stejně stabilní, jako zbytek btrfs. Vypsat varování v okamžiku vytváření je fér – kolik lidí si asi přečte dokumentaci, aby se to dozvěděli z ní?
Samotný princip RAID 5/6 je považovaný za dostatečně známý a prověřený, jakkoliv je to v případě Btrfs úplně jiné řešení. Proto se najde málokdo, kdo by chtěl "experimentovat" s funkcí, kterou spousta alternativ umí stabilně. Uživatelé budou ochotni během vývoje oželet výkon (který lze zlepšovat postupně), ale málokdo si troufne riskovat data. Pokud někomu nejde o data, pak ani nehledá RAID 5/6.
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)
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".
V mirroru je to jednoduché. btrfs je CoW, takže se data zapíšou na oba disky do nových bloků, následně se přepíšou metadata. Metadata jsou uložená na více místech, ale to už je problém, který se musí řešit bez ohledu na RAID – a pravděpodobně platí, že se při startu přečte jedna nepoškozená tabulka metadat a ta platí. Tj. po výpadku napájení se můžete dostat ke starým datům nebo k novým datům, podle toho, co bude zapsané v tabulce metadat, která se použije. Ale nemůžete dost nějaký mix starých a nových dat. A to je to podstatné. (Jinak samozřejmě zápis je aplikaci potvrzen až po zápisu do všech oblastí metadat, takže když aplikace dostala potvrzený zápis, po výpadku už se budou číst vždy nová data.)
Podle lidí kolem btrfs ten problém nebude odstraněn nikdy. Zkrátka vlastnost návrhu (nechci psát "chyba" aby nebyly zbytečné hejty), kterou nejde opravit aniž by se zcela změnila koncepce btrfs.
Existuje ale workaround, který eliminuje problém naboření alespoň metadat - metadata dát na raid1c3 a data na raid5. Tohle btrfs umí - data s jiným raid levelem než metadata.
XFS na Linuxu roky mělo tu vlastnost, že po výpadku napájení zkrátilo na nulovou délku všechny soubory, do kterých se v okamžiku výpadku zapisovalo. Protože by nedokázalo garantovat, že v těch souborech budou nějaká smysluplná data. Všichni s tím počítali a považovalo se za samozřejmé, že XFS jedině na počítač s UPS. Řekl bych, že u btrfs se z toho dělá mnohem větší problém, než to ve skutečnosti je.
Nahodou!
Ja mam atypicky notebook ktery ma 4 SATA disky - je to Vaio Z13Z9E/X, protoze byla doba, kdy nebylo NVMe a udelat neco rychleji? No.. dame tam 4x64GB v RAIDu :-)
Jsou na tom ted Win7 v RAID0 a nejsem si jist, zda tyhle historicke disky tusili o necem jmenem TRIM.. pri bootu si ale Linux cucne metadata o Intel poli a pres device mapper se to slozi do pouzitelneho stavu, predpokladam ze sw raid 5 by tam jelo taky dobre - jen to nedav a z fyzicke organizace moc smysl ty disky tam jsou reseny jako dvojdisky - dve SSD na jednom tistaku, s dvojitym sata pripojenim. No co.. japonci :P