Vlákno názorů k článku
Nepoužívejte RAID5/6 v Btrfs! od bitraefes - musim rict, ze prestoze jsem fanda deklarovanych vlastnosti...

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?

S nadšením jsem testoval btrfs na CentOS 7 a dopadlo to špatně.
Jiní uživatelé mají zřejmě větší štěstí.
Podle mě známých ohlasů některých uživatelů btrfs vyžaduje včera vydané jádro a dnes aktualizované rolling distro. Pak je to vhodné do produkčního prostředí.

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.

Vysvětlení k neměl jsem problém, ale nedoporučuji spouštět scrub: může to vytuhnout. O data ale nepřijdete.

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".

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.

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.

Podle vseho muze dojit k poskozeni pouze v pripade, ze se zrovna neco zapisuje a vypne se elektrika ... coz resi ups.

Tohle slycham pomerne casto, podobne jako: "Nepotrebujeme zalohy, protoze mame raid" anebo "Nepotrebujeme zalohy, protoze mame db replikaci".

> 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?

Jestli se vyplatí to interně číst sekvenčně, to už si pořeší NCQ. Třeba u SSD se vždy vyplatí „seekovat“.

Spouští se balance. Jestli balance provede zápis všech dat na všechny disky nebo jen na ty, kde chybí, to záleží na těch datech a parametrech balance.

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.