Vlákno názorů k článku
Btrfs je podle Oraclu "production-ready" od Jarda_P - Jak muze byt neco "production-ready", kdyz to nema...

Smutne je, ze Oracle sa prepracoval na este vacsiu zumpu ako kedy MS bol. A odividne sa nehodla zastavit... :D

ZFS ho nepotrebuje a je v "production-ready" stavu od roku 2006. Jde o design filesystemu a ne o nejakou magickou utilitu, ktera je v techto pripadech prebytecna.

Hmm a jak te disign filesystemu uchrani pres zavadou HW? Zurnalovani je chymera, fsck by se melo provatet po kazdem kernel panicu a po kazde zavade HW. Zurnalovani chrani konzistanci dat pouze pri vypadku napajeni.

ZFS ani btrfs nemaji zurnal. Jsou to copy-on-write filesystemy.

To sice ano, ale i tak je potřeba recovery mechanismus např. při ztrátě jednoho disku z 5-diskového JBOD. Zda je tento mechanismus v kernelu před mountem (mount se special option?) nebo částečně v userspace v podobě fsck, to už je docela jedno.

Mas v praci par lidi, co delaji na Solarisu, staci se jich zeptat, oni ti to vysvetli, jak to s tim je a v jakych chimerach zijes ;-)

Já myslím, že čas dotyčného by byl produktivněji věnován pravidlům českého pravopisu :-D

"Zurnalovani chrani konzistanci dat pouze pri vypadku napajeni."

Tak to si asi pletes se zalohovanim ne ? Zurnal rozhodne nechrani konzistenci dat, to ani nahodou, na to mas fsync. Zurnal chrani jen konzistenci file systemu a tedy metadat, nehlede na to ze btrfs zadny zurnal nema.

Žurnál může chránit konzistenci dat, pokud se data žurnálují. Ale protože je to extrémně pomalé, tak se to normálně nedělá.

Realita je asi bohuzel jina a tvrdsi nez si pripoustime, jedna btrfs jako snad jeden z prvnich fs pro linux zavadi defragmentaci spojenou prave s COW.

A druha vec je absence fsck, kterou nekde bagatelizuje, zijem v dobe kdy blokova zarizeni lzou systemu o flusovani dat fyzicky na disk, zde muze vznikat velmi slusna nekonzistence pri vypadku, takze nastroj pro offline kontrolu se vic nez hodi.

Rozhodně, vím z vlastní zkušenosti. Používal jsem na notebooku v debianu právě btrfs pro domovský adresář... teď již vím že to nebyl zrovna nejrozumnější nápad, momentálně se při pokusu připojit tento oddíl mi jádro vypíše nádherný výpis ukončený magickými slovy Segmentation fault. btrfsck který zatím jen umí chyby hledat( ne je opravovat ) mi samozřejmě chybu našel... ale co s ní? A riskovat použití toho momentálního btrfsck... ne tak odvážný nejsem ani já.
Btw, ano, tento problém nastal po výpadku napájení... přesněji řečeno jsem vůl a zapomněl jsem notebook zapojit do nabíječky.

Zjevně jak ovladač brtnikfs, tak btrfsck dospějí ke stejnému názoru. Chyba je, že ovladač zpanikuje, to by opravdu neměl. A je otázkou, zda fsck může problém opravit jinak, než jen zahozením dat. Ale s tímhle se právě má srovnat už samotný ovladač, pokud chce brtnikfs imitovat schopnosti ZFS maximálně možně.

ad 1. Co ma spolecneho defragmentace s production ready ? Ano btrfs ma defragmentacni nastroj ze zrejmeho duvodu.

ad 2. Blbost. Blokove zarizeni nesmi lhat o flushovani dat, jinak je dobre akorat jako topne teleso. Flush/fua jednoduse musi fungovat jinak neni mozne garantovat konzistenci dat ani metadat pri padu napajeni.

Pokud lžou, reklamujte je a nekupujte. Kupoval byste disk, kdyby občas zapsal jen třetinu dat?

Co myslite tim, ze brtnikfs zavadi jako jeden z prvnich defragmentaci pro Linux? Myslite tim zvysenou moznost fragmentace v pripade COW? Protoze fragmentaci trpi treba uplne vsechny extXfs, jen to u nich neni moc vyraznejsi.

Co se tyce toho lhani o flushovani dat fyzicky na disk, o tom jsem uz dost slysel, ale v realu jsem tohle u ZFS nepotkal. Dojde-li v pripade ZFS ke stavu, kdy uz samotny filesystem ovladac z nej data nevykouse ani castecne, fsck stejne neudela vice. Pak uz jedine zkusenosti mohou pripadne neco vydolovat skrz "ZFS debugger" zdb. Take jsem se v roce 2006 smal, kdyz ZFS tym rikal, ze fsck proste nebude, nebot netreba. Musim uznat, ze meli pravdu. Dosud treba nebyl

Ano to je prave ono. Kdyz to porovnam s Veritasem tak ten napriklad umi v LVM extrahovat vsecha metadata do txt souboru. Dokonce pri kazde zmene ukada predchozi stav do /etc. Stejne tak umi extrahovat metadata filesystemu. Dokonce kdyz narazite na chybu na FS tak vam (i na Linuxu) vyhodi ovladac do logu nejakou rozumnou hlasku se kterou se da pracovat. Napriklad vezmete cislo inody vydumpujete ji do .txt souboru a poslete to vendorovi emailem.

Podobne i treba Oracle DB (anebo Infomix) maji nastroje na asychronni(online) verifikaci dat. Pokud mate systemy ktere bezi dele nez 10 let, takovehle nastroje potrebujete pomerne casto.

Nejde mi o to, ze bych se ukajel tim, ze mi po rebootu bezi fsck 10 hodin. Jde mi o to, aby byl cely system supportovatelny.