Zalezi na tom o akom distre je rec ked pride na BTRFS. Na Debiane skusane viac ako rokom ma BTRFS velmi nepresvedcilo (boli nejake "oops" pri odmountovani) a celkovo mi to prislo nehotove. Na inych distribuciach moze byt situacia ina. Podla toho kto si to ako opacuje a priohne.
Synology na tom staví svůj business u dražších NASek, takže bych si troufl to označit za produkčně nasaditelné. Samozřejmě je nutné sledovat status, ne všechny vlastnosti jsou tam rock stable.
https://btrfs.wiki.kernel.org/index.php/Status
Ale tak to platí o všem.
Nelibi se jim smutna pravda o jejich betafilesystemu ktery je tak skvely ze check radsi nepoustis protoze by u pouziti snapshotu mohl trvat mesice, balance vlastne taky nemuzes kvuli mnozstvi snapshotu udelat, ale kazdy ti bude tvrdit jaky je to skvely fs ve kterem muzes mit miliony snapshotu... o dalsich polofunkcnich vecech dle wiki nechteji nic slyset a v nejhorsim ti reknou ze potrebujes vice skilled admina nez kdyz mas md, lvm, ext4 nebo zfs nebo cokoliv jineho. Slovami klasika - jsou to picusove.
Mě by jen zajímalo, čeho těmito komentáři chceš dosáhnout. Myslíš, že lidi přestanou používat to co jim vyhovuje jen proto, že to někdo napsal na fórum? Urážkami?
Je skvělé, že v linuxu máme na výběr a každý admin si může vybrat FS podle situace i podle toho, co mu víc vyhovuje. Na každé nasazení se hodí něco jiného. Pokud se mě někdo zeptá na moje osmileté zkušenosti s provozem BTRFS, rád mu je bez obalu sdělím, případně odkážu na vlastní web. Nikomu nic nenutím, jen předávám informace.
Ono totiž, nic na světě není dokonalé. I ty zmíněné md lvm ext4 zfs mají svá zákoutí, o kterých je dobré vědět. LVM sice podporuje snapshoty, ale jejich merge trvá neůměrně dlouho a navíc to LV nelze používat (celkem logicky). ext4 například nemá (stejně jako všechny fs staré generace) checksum dat. md neví, které bloky jsou zapsané a při synchronizaci dělá celý blok device, na kterém může být jen pár GB dat. zfs neumělo do letošního roku odebrat vdev (už to umí, ale je to zatím jen pro opravu konfigurace; už je to i ve FreeBSD 11.2) nebo například nelze smazat dataset, pokud má nějaké snapshoty nebo clony.
Pokud něco z toho admin dopředu neví, tak se může dostat do velmi nelehké situace při použití kteréhokoliv z těchto systémů.
Jinak check ani balance skutečně potřeba není. Balance se postupně integruje do btrfs (podobně jako v minulosti například autovacuum u postgresql) a patrně zůstane jen pro konvert různých typů redundace, a check u ostatních fs zkontroluje stejně jen integritu samotného fs, ale o datech stejně nic nevíte. Od toho jsou checksumy. Tzn pokud je disk nabořený (a smart třeba mlčí), tak to stejně poznáte v logu nebo ve stats. Ono totiž je mnohem pravděpodobnější, že se dřív naboří data, než struktura fs.
Je to velká firma, co prodává NASy po stovkách tisíc kusů a nemůže si dovolit, že lidi přijdou o data.
LULz... https://forum.synology.com/enu/viewtopic.php?t=11985
Staci se podivat do status wiki a udelat si nazor. Nepotrebujes raid5/6? Nepotrebujes stovky snapshotu fs? Nevadi ti performance issue pri reflinkoch? Pak je btrfs vyborna volba. https://btrfs.wiki.kernel.org/index.php/Status
Ty seš teda dobrej hater. V BTRFS není problém desetisíce nebo statisíce snapshotů. Performance issue při reflinku myslíš co? Z logiky věci může být na disku souvisle uložen jen jeden soubor a další "reflinky" při zápisu budou mít bloky rozházené po disku, ale tohle na lineárním prostoru bloků nelze vyřešit jinak. Pokud někdo ví co dělá, tak jsou reflinky perfektní věc a pokud někdo potřebuje ty soubory často měnit, ať udělá jejich skutečnou kopii, nebo ať to edituje na SSD.
A proč bych to měl dělat? Mám tady 20tis snapshotů, FS funguje skvěle a od roku 2010 jsem check nepotřeboval (protože ve starších verzích ani nebyl, což bylo předmětem mnoha haterů). Balance jsem používal naposledy s filtrem -dusage=0, abych vynuloval prázdné grupy. Což už je taky nějaký ten rok vyřešeno přímo v btrfs.
Pokud někdo chce používat quoty, tak si jistě tuto vlastnost pohlídá.
JJ, protože na všech ostatních FS se dělá check pravidelně ;-).
Takže reality check. Některé distribuce už hodně dávno (2008) vypnuly pravidelnou kontrolu ext3 (počet připojení / čas od posledního checku) a spoléhaly se jen na nalezení chyby během provozu (potom nastavily flag pro check během dalšího přípojení). Ext4 bylo upraveno tak, že se check (po chybě) dělal jen na oblasti, která byla používaná, protože check celého FS zvláště u velkých polí trvá fakt dlouho. fsck.xfs vracel automaticky jen nulu, tj během mountování při bootu i při nastavení flagu ve fstabu prostě nic nekontroloval.
Takže většina i starých fs se na pravidelný (pokud jej tedy měly, krom extX snad nikdo) check vyflákla a stačí jim jen check během mountování, kdy driver posoudí stav.
Ja jsem takovy btrfs hater, ze se doma kazde rano modlim hodinu za spadnuti vsech btrfs raidu, za dlouhotrvajici balance u vice nez 100 snapshotu, za co nejvice bugu v btrfs kodu. A kdyz to nezabira, tak vecer obetuji nevinnou divku a modlim se aby otehotnela a narodil se vyvoleny co btrfs bude hejtovat vic nez ja.
Jo a v noci premyslim nad tim jestli to ten Jirsak mysli vazne ohledne btrfs raid 1 nebo je proste sulin jako vetsina z nas. ;)
Po 5ti letech a nekolika vypadcich elektriny natvrdo presne 0 zavad fs. Stejna doba jiny HW ale totozne podminky (v jedne mistnosti) ext3+4 ... v obou pripadech opakovane fs poskozen, v jednom pripade neopravitelna destrukce.
Takze si vyber sam.
Jo a pozor, na tom btrfs bezi ten nestabilni R5.
Pokud využijete vlastnosti jako neomezené snapshoty, send, receive apod., tak ano. Pokud to chcete používat jen jako jiný FS ze staré generace, tak to smysl nemá.
Btrfs se výborně hodí na věci jako správa verzí velkých binárních dat. Uděláte si snapshot vaší xTB subvolume a v průběhu práce na datech pořizujete další snapshoty. Klidně desítky nebo stovky. Každý z nich je zapisovatelný a dále snapshotovatelný, takže klidně můžete vytvářet strom různých stavů původních dat. Je to skvělé na testování. Po ukončení práce tam ty snapshoty necháte nebo selektivně promažete. Na rozdíl od některých jiných systémů lze vymazat i zcela původní subvolume.
To, že je to nespolehlivý zmetek se dozvíte pouze od lidí, kteří neví, s čím pracují a dají btrfs na nevhodné nasazení. Třeba pro těžký databázový provoz se příliš nehodí (ale lze vypnout COW pro datový adresář databáze a potom je to trochu rychlejší). Dále se nehodí pro malé disky. Btrfs má alokační grupy velké 1GB, tzn pokud někdo udělá test na 8GB disku, tak velice rychle zapláče. Je to pro TB disky.
Zkrátka, je potřeba vědět, kde a proč to chcete nasadit a potom vám odvede skvělou službu.