RAID5/6 v Btrfs ještě nikdy nebyl prohlášen za stabilní, ale Goffredo Baroncelli nedávno objevil, že scrub v některých případech nesprávně počítá paritu, což může mít fatální následky.
Zatím se zdá, že bude potřeba přepsat celý kód, který se o RAID5/6 stará a to bude zřejmě nějakou dobu trvat. Uživatelé jsou důrazně a oficiálně nabádáni, aby RAID5/6 v Btrfs nepoužívali.
(zdroj: phoronix)
musim rict, ze prestoze jsem fanda deklarovanych vlastnosti btrfs, raid v rezii btrfs moc nechapu. kdyz nam celskem dost dobre funguje sw raid dodavany s jadrem, proc tristit sily na fs based raid?
a opet, prestoze jsem fanda btrfs, uz jsem diky nemu prisel o tolik hodin casu, ze musim varovat i pred beznym btrfs nasazenim. btrfs nasazene na ubuntu 14.04 mne dvakrat tak vypeklo, ze mu to dlouho nezapomenu.
jake mate zkusenosti vy a cemu se ma clovek u btrfs vyhnout, aby to fungovalo spolehlive?
dali byste si na produkcni nasazeni btrfs?
Používám btrfs single (bez RAIDu), btrfs RAID 1 a btrfs RAID 10 a neměl jsem s nimi zatím problém, jen bych pro jádra starší než 4.4 nedoporučoval spouštět scrub (lze místo něj použít balance, ale trvá to). Máme ho i v produkci (bez RAIDu), třeba správa LXC virtuálů či rotace zálohování je díky snapshotům parádní.
FS RAID má mnoho výhod, které MD RAID nemůže mít. Třeba pokud FS zjistí, že načtený blok neodpovídá checksumu (silent corruption), může načíst jinou kopii. Nebo můžete mít různé úrovně pro data a pro metadata, takže procházení adresářů bude používat rychlý RAID 10, ale data budou používat úspornější RAID 6. Btrfs plánuje, že různé úrovně budou moct mít i jednotlivé subvolumy, přičemž stále budou sdílet místo na fyzických discích. Šlo by dělat i to, že při velké zátěži se začnou data ukládat jako RAID 10 a teprve později se na pozadí převedou na RAID 6.
Já zase narazil na problémy jako že nelze vypnout autodefrag nebo že mount filesystému trvá minutu. I přesto to používám na zálohy, ale na produkční stroj už bych to asi nedal (jednou jsem tu chybu udělal).
Pak je tam „super“ věc že CoW způsobí fragmentaci souborů uvnitř kterých jsou vlastní datové struktury (databáze, image virtuálů) a CoW nejde vypnout per-subvolume a když se vypne tak většina výhod btrfs zmizí.
> Třeba pokud FS zjistí, že načtený blok neodpovídá checksumu (silent corruption), může načíst jinou kopii.
1) To může MD RAID udělat taky, FS mu řekne, jestli nemá jinou verzi, a on to zkusí přečíst z jiných disků.
2) Už jste vůbec někdo viděl silent data corruption, ideálně na stroji s ECC? Já ne. Jak to vypadá, má to flipnutý jeden bit, nebo je celý blok/skupina bloků blbě? Náhodně blbě, nuly, jedničky?
Odpovim trochu mimomisovite, prtz je zjevne rec o skutecnych discich a ne parodiich v podobe SD karet, ale prece. Nainstaloval jsem si ARM Debian na 8GB microSD. Po chvili pouzivani to zaclo nejak drzkovat, ze nejde tusim snad primo /bin/bash (nebo neco hodne podobnyho). Podival jsem se do nej hexdumpem, a zacinal ".E!F..." (prehozenejch bylo myslim vic nez 1 bit, ale jistej si uz nejsem). Nejak jsem se nechtel se situaci prilis babrat, tak jsem to preeditoval na "L".
CoW nejde vypnout per-subvolume a když se vypne tak většina výhod btrfs zmizí.
To sice zatím nejde, ale můžeš si nastavit chattr +C na adresář, ve kterém budeš mít soubory db a pro ty je potom COW vypnuto. Některé instalační skripty pro databáze to tam mají defaultně.
Takže to sice nejde per celou subvolume, ale máš k disposici mnohem jemnější granularitu per soubor nebo per nový adresář. ;-)
MD RAID neumí rozumně dělat RAID přes různě velká zařízení. Na btrfs můžeš mít RAID1 z 1TB, 2TB a 3TB disků a každý blok je právě na dvou discích.
Bohužel i já jsem narazil na bug v btrfs, kdy z nějakého důvodu vrací IO error při čtení souboru, ale nic nezaloguje a rebootem se to spraví. Bohužel nevím jak to odladit, takže to tam furt je (i když teď už se to delší dobu neprojevilo, tak to možná opravili).
Já btrfs používám především kvůli jeho snapshotům. Nepoužívám jiný RAID level než 1, pokud ho potřebuju, udělám btrfs na MD RAIDu.
raid v rezii btrfs moc nechapu. kdyz nam celskem dost dobre funguje sw raid dodavany s jadrem, proc tristit sily na fs based raid?
Krom již uvedeného (Sten, Jenda) se jedná také o distribuci volného místa. Všechny subvolumes sdílí místo na všech zařízeních (a je navíc možné nastavit quoty) - toto s blokovým zařízením neuděláte (ok, je možné nad mdadm nasadit lvm a thin provisioning, ale to není ani rychlé, ani jednoduché). Dále je to rychlost obnovy po výpadku disku, btrfs ví (na rozdíl od mdadm), které bloky jsou obsazeny daty a při výměně disků synchronizuje pouze ty (takže je to mnohem rychlejší).
Navíc to není tříštění sil. Koncept redundace btrfs je zcela jiný, než koncept klasického raidu. V Btrfs není nikde ukrytý kód zkopírovaní z md.
dali byste si na produkcni nasazeni btrfs?
Provozuju to tak několik let ke své maximální spokojenosti.
Kazdy lepsi HW (cimz myslim specielne diskovy pole) upousti od blokovych raidu. Predevsim prave proto, ze maji spoustu ruznych omezeni. Kdyz si dneska koupis pole, tak vubec nemusis resit, ze tam mas pomaly disky, rychly disky, pomaly a rychly ssd ... proste se ti to tvari jako jedno velky misto .... a v zavislosti na pravidlech jaky tomu nastavis to data samo migruje na ruzny typy uloziste. Tohle na blokovym raidu nejses schopnej rozumne realizovat.
BTW: Provozuju R5 na btrfs a nemam s tim problem. Podle vseho muze dojit k poskozeni pouze v pripade, ze se zrovna neco zapisuje a vypne se elektrika ... coz resi ups.
Chyba se projeví, když jeden z disků vrátí špatná data. Správně by se měla data ze zbylých disků dopočítat, to však nefunguje.
Výměna vadného disku za nový a dopočítání dat také často selže, takže RAID5 je v současnosti bezpečný jako disky bez RAID nebo i horší.
Asi bych to radši zkonvertoval na RAID10.
> které bloky jsou obsazeny daty a při výměně disků synchronizuje pouze ty (takže je to mnohem rychlejší)
A opravdu to je? Při docela obsazeném disku se stejně vyplatí číst to sekvenčně celé, protože je to rychlejší než seekovat na obsazené oblasti.
Btw. jak vlastně probíhá obnova RAIDu? Nespouští se balance a tudíž to místo čtení existujících disků a zápisu na nový úplně všechna data čte a zapisuje znova?
Ad Jestli se vyplatí to interně číst sekvenčně, to už si pořeší NCQ - NCQ má délku fronty 32 položek, takže s výkonem pomůže, ale nezachrání to. SSD umí "seekovat" daleko rychleji, jenže se vždycky čte minimálně jedna page (2-16kB), a pokud zapisujete do page která není prázdná, tak se musí smazat obsah celého bloku (256kB-4MB). Sice vám trochu pomůže flash translation layer, resp. wear leveling, ale i tady se vyplatí používat velké requesty.
> Jestli se vyplatí to interně číst sekvenčně, to už si pořeší NCQ.
Nedokážu si představit jak NCQ přeskládá čtení celého B-tree s náhodným rozházením terabajtu bloků. Nehledě na to, že NCQ neví, že sousední bloky nemusí nechat na pokoji.
> Třeba u SSD se vždy vyplatí „seekovat“.
Nevyplatí. Nevím, jestli je bottleneck v řadiči nebo v disku, ale zasypat ho čtyřkilovými requesty má režii.
vyhody btrfs viz zde:
http://multi.xeres.cz/unix/filesystem-btrfs
samozrejme jakykoli FS volit s rozvahou
