Názory k článku Dva měsíce s Btrfs: zkušenosti a postřehy

Btrfs jsem chvíli také zkoušel a počáteční nadšení z výkonu bylo veliké. Bohužel do hry vstoupily diskové cache a já si to v první chvíli neuvědomil.
Měl jsem na něm Gentoo Portage (asi 140k prťavých souborů. Brát s rezervou, nejsem u PC s Gentoo) a synchroznizace emerge --sync, trvala cca 1:13. Když jsem se vrátil k Ext4, tak je to cca 1:06, takže to s Btrfs trvalo asi o 10% déle.

btrfs je evidentne obslehly zfs, tedy stejne jako tam je kazda zmena diky copy-on-write a.t.o.m.i.c.k.a! tedy se proste zmena zapise nebo nezapise (a zustava predchozi stav). a tedy zadny fsck neni a nebude potreba.

To je sice hezká teorie, ale v praxi může nastat spousta situací, které prostě můžou fs poškodit nezávisle na tom že změny v btrfs jsou atomické. Můžou to být chyby v kódu btrf samotného, chyby v nějakém jiném ovladači. Nebo se objeví problém s HW. Nebo to může způsobit výpadek elektřiny. Nebo...
Takže fsck potřeba prostě je.

Hmmm, pripomina mi to debatu nad ZFS par let zpet. I tehdy zaryti UFSaci necetli dokumentaci a chteli fsck... Vsechna data jsou ulozena s CRC32 checksumy, ktere jsou pri kazdem readu kontrolovany, abys nedostal corrupted data. Takze pokud moci mermo potrebujes vyuzit disk io a cpu, misto fsck pouzij find + cat se stejnym efektem.

btrfs se muze rozbit, povedlo se mi to nekolikrat (hlasil jsem to i do btrfs mailing listu), zejmena pokud nad btrfs pracuje dm-crypt nebo jsou vyple barriery... pak staci jeden vypadek proudu a je to

Pripomina mi to moji zkusenost s Reiser4. Skvely system, rychly, ma tailpacking a transparentni kompresi, ale jednou mi vypadek shodil server pri zapisu, par bloku odeslo do magnetickeho nebe a pulka OS byla v ****. Chce to nejenom fsck, ale musi byt i odladene.

Je možné už v btrfs mazat snapshoty? Tohle mě asi před rokem docela odradilo...

Ano je.

je, ale az s novym kernelom, myslim, 2.6.35 a lepsi

Jde mi to tu i s 2.6.32 a btrfs-tools 0.19+20100601.

Otázka totiž je, co se stane, když se v souboru mění jen několik bloků?

Pokud se celý soubor znovu zapíše za konec souborového systému, tak to bude pomalé a rychle to vyžere skutečný prostor (řeší btrfs nedostatek místa?).

Když se připíšou jen změněné bloky, tak při následném sekvenčím čtení změněného souboru bude soubor rozdroben. To nemusí vadit na flashových pamětích (pokud jsou bloky souborového systému zarovnány na hranice bloků blokového zařízení), ale na magnetické rotující paměti to znamená přenastavování hlaviček a tragický propad v propustnosti.

Dojde ke fragmentaci. U současných disků (SATAII nebo SATA 3) to ale moc nevadí, protože umí NCQ, samotné btrfs se také snaží čtecí operace nějak optimalizovat. Ale i kdyby to vadilo, btrfs umí defragmentovat.

Já btrfs nejprve zkoušel na separé oddílu a potom jsem zkoušel i instalaci Ubuntu.

Instalace byla neskutečně pomalá (2h místo 15m). Instalace updatů pak byla taky _neskutečně_ pomalá. Důvodem je, že si to nerozumí s dpkg. Jde o to, že dpkg volá fsync, který na btrfs z nějakého důvodu trvá dlouho (možná proto, že jiné FS to "flákají"). Našel jsem i patch, který poctivost fsync nějakou heuristikou omezuje. Řešení z druhé strany je ohákovat dpkg (v bugzile je návod na vyrobení knihovny s prázdným fsync a její vnucení přes LD_LIBRARY_PATH).

S hlediska vlastností FS je asi správným řešením udělat před začátkem updatů snapshot a fsync zavolat až na konci. Myslím, že Fedora to tak nějak dělá.

Já btrfs nejprve zkoušel na separé oddílu a potom jsem zkoušel i instalaci Ubuntu.

Instalace byla neskutečně pomalá (2h místo 15m). Instalace updatů pak byla taky _neskutečně_ pomalá. Důvodem je, že si to nerozumí s dpkg. Jde o to, že dpkg volá fsync, který na btrfs z nějakého důvodu trvá dlouho (možná proto, že jiné FS to "flákají"). Našel jsem i patch, který poctivost fsync nějakou heuristikou omezuje. Řešení z druhé strany je ohákovat dpkg (v bugzile je návod na vyrobení knihovny s prázdným fsync a její vnucení přes LD_LIBRARY_PATH).

S hlediska vlastností FS je asi správným řešením udělat před začátkem updatů snapshot a fsync zavolat až na konci. Myslím, že Fedora to tak nějak dělá.

Prave toto pomale dpkg ma zarazilo ked som sa pokusal system instalovat. A to som mal v plane si pomocou tohoto fs a lzo zrychlit moj starsi disk na notebooku. Este to zvazim.

... tak Snapshoty vypadaji jako u NetAppu ... coz je spicka na snapshoty a ani 100 snapu ji nezpomali, nebot data v tzv snapshoty jsou aktulani, i kdyz je to slozite, proste se pise jinam a stare data se nechaji byt a udrzuje se jakasi tabulka ... zatimco stary pristup, napr i u LVM2 je takovy, ze udelam snapshot do jineho LVM2, kdyz chci neco zmenit, tak se stara data nejprve zkopiruji do snapshotu(bloky) a pak se prepise ... kdyz udelam snapshotu vice, poslu server do kopru ;-))
netapp tim netrpi, ZFS a BTRFS taky ne ;-))

Jinak tomu cemu rikas ty shodne bloky jen jednou, se jmenuje deduplikace ... je to dobry sluha a spatny pan, kdyz se to rozsype ... data nejsou ;-)) ... nam se takhle rozsypal netapp diky chybe v ontapu ... nastesti jen na zalohach ;-)) ... ona totiz pak neexistuje moznost, jak data spojit, proste je tam jeden blok a tabulka odkazu uz neni ... vysledek je naprosto nekonzistentni stav, kdy nikdo nevi, ktery soubor je OK a ktery ne ;-))

Jinak ja delam snapshoty automaticky, i se automaticky odmazavaji, dale delam vzdalene snapshoty, coz uz je skutecna zaloha a pres NDMP je zase muzu zkopirovat zpet ... jestli bude tohle umet BTRFS, tak to bude bobma, nebot pak muzu delat nekonecny increment s desitky TB dat a zaloha bude trvat v radu sekund az minut, vejde se na jiny server a idelane kdyz bude i na paskach ....
Protoze zalohujte takovehle mnozstvi dat ... fullBCK trva v radu dni, Tivoli se na takovem poctu serveru zhrouti ... a tak je reseni zarlohovat pres blokove snapshoty a replikace ....

30GB databázi jakou? Zálohovanou nebo 30GB mediadb? To první mi přijde jako zbytečnost a v životě jsem to neviděl, to druhé mi zní divně, takový setup...

"Pocitaji s tim ze ty stavajici vyhodi a vezmou novy co umeji TSM 6." -
Tak to musí být idiot buď zaměstnavatel, že si myslí, že se lidé neumí sami učit, nebo zaměstnanci, že se neučí ani kdyby měli být vyhozeni. Ale v obou případech je takový zákazník zlatý důl.

Zadnou, nikdo to zde nenasadi, pouziva se zde vice SW: legato Networker na male veci, NetBackup na male serverovne s netappem.
Pak ve velke serverovne Netapp a dale SW napasny nam na miru, ten dela v clusteru, zalohuje desitky PT dat na asi 1000 mechanik .... ne opravdu TSM, Legato Networker, NetBackup by se z toho sesypal, testy se delaly.
nejvetsi obemy dat se migruji prave na NetAppy, nebot se umi rychle replikovat do jinych netappu.

V tomto je clanek trochu matouci: "Vytvořit snapshot je možné jen v rámci celého disku, nikoli adresáře."

Snapshot se nevytvari v ramci celeho disku, ale v ramci subvolume. A pocatecni konfigurace fs obsahuje prave jeden takovy subvolume. Dalsi samozrejme muzete vytvorit, napr. btrfs subvolume create /home/xy/moje_du­lezita_data. Takovy subvolume pak muzete normalne pouzivat jako jakykoliv jiny adresar. Snapshoty takoveho "adresare" jsou ale opravdu jen v ramci subvolume a ne celeho disku.

Principialne neni mezi subvolume a snapshot na urovni btrfs neni rozdil. Nebylo autorovi divne, ze pro smazani snapshotu pise btrfs subvolume delete...?

Dalsi informace najdete v btrfs wiki. Btrfs pouzivam pul roku ;)

https://btrfs.wiki.kernel.org/index.php/SysadminGuide

Sekce subvolumes.

V moderním filesystému by se podle mě nemělo řešit "volné místo" a tímto termínem označovat místo kdykoliv uvolnitelné pro uživatelská data. Nechť je disk plný snapshotů a nechť nová data automaticky používají bloky hodně starých snapshotů. Jednou ten disk mám koupený, tak ať je využit na max.

ma niekto skusentosi s space_cache? ja ked mam kompresiu aj space cache naraz tak vykonnost ide prudko dole, ale ked mam len jedno alebo druhe tak ide hore. mam to na starom eee co ma 4GB ssd (isiel som podla tohto: https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options)

Testy na phoronixu dopadly podobne, takze chyba nebude u vas. Je to prece jen hodne cerstva featura (cache).

Neviem najst nejake dobre porovnanie tychto dvoch fs (to na phoronixe kde to testuju na atome sa mi az take dobre nezda..). Pacia sa mi tie ficurky, ale vo vykone skoro vsade vyhrava ext4. Myslite, ze sa btrfs v dohladnej dobe dostane do stavu, ze by vykonom prevalcoval ext4?

No ono asi hodne zalezi na nastaveni a take na tom jakou maji ty testy vypovidaci hodnotu.

U me treba pri zaple kompresi dopadl tak, ze doba kompilace IDE klesla z 16 minut na 13 minut a vysledne artefakty zabiraly cca o 0.5 GB mene.

Myslim, ze pri bezne praci rozdil mezi ext4 a btrfs nepoznate, ale treba se pletu. Ja uz se ale k ext4 nevratim :)

Dokud nad ním nezačnete používat virtualizaci. Brutálně se pak virtuály zasekají při větších io operacích.

Jinak ho bez problémů používám na všechny normální data na všech diskových oddílech větších než 1TB už víc jak rok.

Na to ale upozornuji i autori, ze z povahy veci to neni uplne ono kdyz mate velky soubor a v nem nahodne menite data, tj. typicky pripad pro virtualizovane stroje.

Zkousel jste pro tento pripad "-o nodatacow"?

Pro virtualizaci doporučuji nepoužívat virtuály v souborech, ale v LVM.

Nedávno som dal btrfs na nový počítač s 2x1.5GB SATA HDD s dmraid (Ubuntu 10.10). Subjektívne sa mi to zdá pomalšie ako ext4 na staršom notebooku. Nemeral som to, ale najviac čakám na io operácie a to i pri takých veciach ako spustenie browsera (chromium) hoci s iba 3 tabmi, alebo načítavanie adresára s veľkým množstvom súborov. Preto sa chystám na kompletný formát a vrátenie sa k ext4 a mdraid.

ZFS existuje v produkční kvalitě a je otestován na úplně jiné úrovni než Btrfs. ZFS ale není na Linuxu (alespoň ne stabilně). Čili momentálně je ZFS jasná volba. Možná je "Btrfs na papíře" lepší než "ZFS tady a teď a vyzkoušený", ale to nemá význam porovnávat. Až bude mít Btrfs všechny deklarované a vysněné vlastnosti, tak ZFS bude pravděpodobně taky někde jinde než je teď.

Který byste si vabryli? Záleží na co. Ale momentálně bych si Btrfs nevybral na nic jiného, než na data na kterých tak moc nezáleží.

Btrfs sleduji od okamžiku, kdy se tento FS objevil v kernelu. O snapshotech subvolumes, tedy vnořených adresářů dle libosti definovaných uživatelem, tedy již delší dobu vím a považuji to za skvělou věc při proměnlivém systémovém i uživatelském prostředí u roll-on distribucí. S grubem2 odpadají problémy se zaváděním, což mám ověřeno u kolegy. Výkon souvisí s optimalizací pro práci s malými soubory, takže v případě multimédií je moudré se poohlédnout jinde. Btrfs se ale hodí přímo na systém a proto je nutné jej testovat právě zde. Při pečlivé instalaci není btrfs méně stabilní než tradiční FS, spíše nemá odladěné některé funkce, což je ale avizováno. Wiki je hodně solidní zdroj informací, kdo nečte, může pak nadávat jen sobě...