Chris Mason poslal jaderným vývojářům požadavek na zařazení nové verze Btrfs do připravovaného linuxového jádra 3.18. Hlavní novinkou je vylepšený kód pro recovery a opravu RAID, ale byl také opraven fsync a mnohé další chyby. Celkem přibylo asi 2000 řádků kódu. Detaily naleznete v pull requestu.
Btrfs vylepšuje kód pro opravu poškozeného RAID pole
13. 10. 2014
14
nových názorů
-
Petr Baláš (neregistrovaný)
RAID0 a RAID1 se IMHO dá risknout, RAID5,6 bych se zatím bál. Ale i tak je to zatím docela syrové - dost mi chybí něco jako /proc/mdstat abych si mohl vypsat stav raidu (používám svoje kernely bez initrd a nabootovat z btrfs s raid1 nelze :-(, při pokusech jsem ale dokázal nabootovat s polem v defradovaném režimu a "btrfs fi show" mi vesele ukazovalo, že pole má dva disky, až pokus o scrub mi řekl, že pole opravdu není komplet - uááááá). Ostatně furt nějak nejsem schopen pochopit, proč vůbec je potřeba "btrfs device scan" - IMHO by si toto měl řešit kernel sám o sobě.
-
-
Trubicoid2 (neregistrovaný)
Taky nejak nechapu proc pro root na raid1 je nutny initrd :(
Data mam ted na raid5 a zatim v pohode. Scrub jednou za tyden, trva asi 5 hodin, jsou to 4x4TB disky, ale ne plny a btrfs scrubuje jen data na rozdil od mdadm.
Vyhoda je, ze muzes konvertovat lehce mezi raid5 a treba v mym pripade raid10 pomoci balance.
-
"dost mi chybí něco jako /proc/mdstat"
Nic takového není možné. V Btrfs se multidevice dělá tak, že se jednotlivé bloky souboru zapisují na různém disky. Takže můžete provozovat R1 nad lichým počtem disků a bloky se zapisují vždy na dva. Libovolné dva. Pokud do takového systému přidáte další disk a neprovedete btrfs balance a tento nový disk vzápětí vypadne, tak na něm nejsou žádné bloky. Snad si rozumíme.
MD raid je blokové zařízení sestavené z jiných blokových zařízení. Když jedno vypadne, tak se přesně ví, co chybí.
Takže místo /proc/btrstat aka mdstat se používají příkazy jako balance, scrub. Scrub do systémového logu vypisuje jména poškozených souborů apod. (Takže máte referenci co případně vytáhnout ze zálohy apod.)
Zkrátka chci tím říct, že je třeba se naučit myslet trochu jinak, btrfs multidevice není fs nad raidem. Je to propojené dohromady.
-
Petr Baláš (neregistrovaný)
Jak funguje btrfs IMHO docela vím a chápu proč, co a jak. Ale chybí mi (resp. možná jen nevím co použít) něco, kde na jednom místě rychle zjistím, zda je nějaký problém a pokud ano, tak na kterém disku. Asi nejblíž tomu je spustit si "btrfs scrub status" a uvidím výsledek posledního scrubu (ten pouštím 1x denně z cronu) ale zde si musím nejprve hledat, na kterých discích mám nasazené btrfs a pak to spustit pro každý disk. Proti "cat /proc/mdstat" jeto hromada práce navíc :-)
-
j (neregistrovaný)
Narazil jsem na par rozbitych systemu s timhle fs a nebylo to opravitelny. Narozdil od ext, kde se vetsinou da aspon neco vycucat. Zpusobeno nekorektnim vypnutim, ale to by slusnej FS mel rozdejchat.
Samo, muzem zacit probirat zalohovani ... ale clovek i kdyz zalohu ma, radsi by mel aktualni data.
-
Takto položená otázka nedává smysl. Chápu, že srovnáváte ext4 nad raidem (asi mdadm) s btrfs multidevice R5.
Do BTRFS R5 bych (zatím) nešel, do čeho bych ale šel je btrfs nad mdadm R5. Tedy to, co chcete provozovat s ext4.
Získáte tím všechny výhody btrfs vycházející z cow a vyhnete se rizikům plynoucí ze současného stavu implementace multidevice v btrfs (RAID 0 a 1 ok, RAID 5/6 zatím nekompletní).
Navíc, pokud se rozhodnete pro ext4 a za měsíc si to rozmyslíte, tak to lze docela snadno překonvertovat. Jedním příkazem (no a příslušnou změnou ve fstabu).
Sám provozuju již několik let (4+) BTRFS mirror (střídavě dva nebo tři disky) a to funguje zcela bez problémů. (Jen kdysi dávno na jádře 2.6.18 se to úplně nevyrovnalo se ztrátou disku, jenže tehdy měl btrfs 2 roky.)
ČLÁNKY DO MAILU