Dotaz: Pár otázek k Btrfs

[Franta]

Dost vážně teď zvažuji produkční nasazení Btrfs. Něco mám načteno, něco vyzkoušeno, ale přeci jen bych uvítal nějaké praktické zkušenosti a rady

Chci použít FS pro inkrementální zálohy - udělat snapshot, ten inkrementálně odzálohovat (tzn. přenést jen změny) na jiný stroj. Staré snapshoty na obou stranách průběžně mazat a nechávat si jen pár posledních. Je to dobrý nápad? Je to spolehlivé? Pokud by tohle nešlo, tak pro mne v podstatě Btrfs padá - chybí hlavní důvod ho použít.

Disk bude sloužit jen pro data, systém bude jinde - dávat pod Btrfs LVM je blbost, ale co MBR nebo GPT? Jsou k něčemu dobré, nebo můžu dát s klidem Btrfs na celý fyzický disk? (ve skutečnosti vzdálené diskové pole, ale o tom místní OS neví a nemusí řešit žádné RAIDy nebo spojování více disků dohromady).

Od jaké verze jádra považujete Btrfs za "dost dobře použitelné"?

Komprese asi není dobrý nápad. Jsou nějaké další věci, na které si dát pozor?

Jak s defragmentací? Radši ruční než automatická? Jak často ji spouštět? Jaké procento zaplněnosti disku je podle vás v pohodě a kdy už byste běželi přidávat další disky?

Odpovědi

[Aleš Janda]

Chci použít FS pro inkrementální zálohy - udělat snapshot, ten inkrementálně odzálohovat (tzn. přenést jen změny) na jiný stroj. Staré snapshoty na obou stranách průběžně mazat a nechávat si jen pár posledních. Je to dobrý nápad? Je to spolehlivé?

Nemám zkušenost s přenosem změn na nový stroj. Ale samotné snapshotování a mazání starých - ano, je to spolehlivé, používám.

Od jaké verze jádra považujete Btrfs za "dost dobře použitelné"?

Cokoli tak rok zpátky je úplně v klidu.

Komprese asi není dobrý nápad.

Proč by nebyla? Naopak je to jedna z killer feature. Pokud všechno transparentně nešifruješ nad BTRFS, určitě to má smysl.

Jak s defragmentací? Radši ruční než automatická? Jak často ji spouštět? Jaké procento zaplněnosti disku je podle vás v pohodě a kdy už byste běželi přidávat další disky?

Defragmentaci to sice nějakou umí, ale nikdy jsem nezaznamenal žádný rozdíl. Dokonce starší jádra (starší než hodně nové) defragmentovaly v rámci jednoho snapshotu; tj. pokud byl jeden stejný soubor ve dvou snapshotech (nezměnil se), v tom jednom se zkopíroval na nové místo, čímž najednou začal zabírat dvakrát tolik místa.

Jsou nějaké další věci, na které si dát pozor?

Je to pomalý. POMALÝ. Fakt hodně. Už instalace systému bude tak 2-3x delší (a aptitude obecně si na tom láme zuby). Pokud se ti zpočátku bude zdát, že to není tak hrozné, časem to bude jenom pomalejší a pomalejší. Údajně je to kvůli tomu, že copy-on-write systémy se z principu strašně fragmentují, ale řekl bych, že je v tom i něco jiného, protože defragmentace moc nepomáhá. Občas se stane, že se systém tak nějak na 5-20 sekund zasekne, kdy svítí jen disk. A třeba zkopírovat víc než 1 GB velkej soubor v rámci disku taky neprobíhá úplně plynule (po tom GB dojde nějaká cache nebo co a strašně to laguje. A to dokonce i na SSD, něco je prostě blbě s BTRFS).

Nicméně pokud rychlost pro tebe není zásadní a oceníš snapshoty (a kompresi), můžu doporučit

[BigWrigley]

Je to pomalý. POMALÝ. Fakt hodně. Už instalace systému bude tak 2-3x delší (a aptitude obecně si na tom láme zuby). Pokud se ti zpočátku bude zdát, že to není tak hrozné, časem to bude jenom pomalejší a pomalejší.

Pod tohle bych se podepsal. Myslel jsem, ze se Debian na btrfs snad ani nenainstaluje. Take nevim presne, co je duvodem, ale subjektivne byla prace s diskem tak 3-4 pomalejsi, a to jsem mel system na SSD. Po 14 dnech jsem migroval na ext4.

[erino72]

Je ta instalacia dlhsia aj pri inych systemoch? Ubuntu, Fedora?

[BigWrigley]

Neskousel jsem. Bohuzel nemam cas si s tim moc hrat, ale subjektivne se Debian po instalaci choval neuveritelne line. Kompresi jsem nepouzival. Ale obycejna prace s fs, rozumej napr otevreni adresarove struktury v Doplhinu v KDE byla velmi citelne pomalejsi. A to nemluvim o napr. dekompresi zdrojaku jadra.

Neprisel jsem na to, co je spatne, a indikuje mi to, ze na realne nasazeni je brzo.

[Heron]

Co dělám špatně?

BTRFS:

wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.13.6.tar.xz

time tar xf linux-3.13.6.tar.xz

real    0m6.016s
user    0m5.932s
sys     0m1.428s

du -sh linux-3.13.6
414M    linux-3.13.6

TMPFS "ramdisk":

time tar xf /home/tomas/test/linux-3.13.6.tar.xz 

real    0m5.874s
user    0m5.904s
sys     0m0.616s

[BigWrigley]

Nevim. Zkusim to znovu a dam vedet

[Heron]

Zkus. Btrfs má default commit time 30s (například ext3 má 5s), takže se ten archiv stihne rozbalit do iocache ještě dřív, než se první soubor dostane na disk (nehledě na to, že se těch cca 400MB zapíše v podstatě sekvenčně, takže též za pár sekund).

[BigWrigley]

Zkousim to, ale nemam dost mista na partition s btrfs, jen 512MB.

root@Emil:/mnt/ramdisk# time tar xfj linux-2.4.0.tar.bz2 

real    0m2.345s
user    0m2.340s
sys     0m0.248s
root@Emil:/mnt/ramdisk# 

root@Emil:/mnt/tmp# time tar xfj ../ramdisk/linux-2.4.0.tar.bz2 
tar: linux/drivers/net/atari_bionet.c: Cannot write: No space left on device
tar: linux/drivers/scsi/FlashPoint.c: Cannot write: No space left on device
tar: linux/drivers/scsi/sym53c8xx.c: Cannot write: No space left on device
tar: linux/drivers/isdn/hisax/l3dss1.c: Cannot write: No space left on device
tar: linux/drivers/isdn/hisax/l3_1tr6.c: Cannot write: No space left on device
tar: linux/drivers/usb/usb-ohci.h: Cannot write: No space left on device
tar: Exiting with failure status due to previous errors

real    0m3.082s
user    0m2.880s
sys     0m0.508s
root@Emil:/mnt/tmp#

Coz je dobre. Zkusim jeste defaultni jadro, mam 3.8-trunk-amd64, mozna se tedy neco zmenilo.

[luky]

Todle porovnani nerika skoro nic, protoze se to rozbalilo do cache, coz se nestane, pokud bude vetsi tlak na pamet, pripadne pokud aplikace syncuje data na disk, coz je IMO i pripad instalace systemu.

[BigWrigley]

Cache ma urcite vliv ale pri instalaci se pouziva take a fs nejspis nebude primountovany synchronne, ne? IMHO by system musel mit kriticky malo pameti, aby velikost cache tlacil hodne dolu.

Nejaky napad, jak merit lepe?

[luky]

Cache ma urcite vliv ale pri instalaci se pouziva take a fs nejspis nebude primountovany synchronne, ne? IMHO by system musel mit kriticky malo pameti, aby velikost cache tlacil hodne dolu.

Ne, ale balickovac bude pravdepodobne dost casto volat sync, aby byl system v konzistentnim stavu, kdyby se neco pokazilo.

Nejaky napad, jak merit lepe?

Napriklad pri mereni rychlosti zapisu opavdu merit dobu, nez se data zapisi na disk. Jinak se meri neco, na cem se kod FS vubec nepodili.

Poradit nekomu nasazeni brtfs bez znalosti zateze mi neprijde nejlepsi napad, v tom pripade je rozhodne lepsi ext4 nebo xfs (+ pripadne LVM), protoze je mnohem mensi sance, ze dany clovek narazi na "prekvapeni".

[Mac_CZ]

Všiml jsem si, že každý kdo si stěžuje na pomalost btrfs, používá kompresi. Já kompresi nepoužívám a v rychlosti ani po roce není rozdíl proti ext4. Takže komprese je opravdu "killer" feature.

[Heron]

"Je to pomalý. POMALÝ. Fakt hodně."

NENÍ POMALÝ. NENÍ. FAKT VŮBEC.

Ono by se možná chtělo zamyslet nad tím, při jaké operaci je to pomalé. Tou operací je fsync (a příbuzné). Ano, fsync je na btrfs pomalejší než na některých jiných fs. To je ale vše. Naopak, při sekvenčních zápisech je HODNĚ RYCHLÝ.

Z toho plyne co? Že na BTRFS nebudeme dávat věci, které hodně volají fsync. Pro toto nasazení se zatím nejspíše nehodí. Otázkou taky je, zda tuto nepříjemnost nevyváží další featury, které jinde nejsou.

[Heron]

Chci použít FS pro inkrementální zálohy - udělat snapshot, ten inkrementálně odzálohovat (tzn. přenést jen změny) na jiný stroj.

Já tohle dělám už déle než dva roky (viz článek http://www.abclinuxu.cz/clanky/btrfs-lepsi-system-souboru-praxe#inkrementalni-zalohovani-pomoci-snimku-a-rsync) a je to bez problémů.

Teď si chci (až bude v geologicky dohledné době trochu víc času) pohrát se send / receive (zbavit se rsyncu) (viz http://www.heronovo.cz/dva-zpusoby-zalohovani-snapshotu-btrfs/). Co jsem zkoušel, tak to funguje dobře a rychle, ale dlouhodobější zkušenosti ještě nemám.

Za mě tedy ano, je to dobrý nápad, jak je to spolehlivé si musí každý odpovědět sám.

Disk bude sloužit jen pro data, systém bude jinde - dávat pod Btrfs LVM je blbost, ale co MBR nebo GPT? Jsou k něčemu dobré, nebo můžu dát s klidem Btrfs na celý fyzický disk? (ve skutečnosti vzdálené diskové pole, ale o tom místní OS neví a nemusí řešit žádné RAIDy nebo spojování více disků dohromady).

Osobně to mám nad partišnou (MBR), což bych i doporučoval spíše z důvodu evidence (některé OS, když vidí prázdný disk bez partišen, tak se na něj vrhnou, ovšem pokud je tam pro ně neznámý oddíl, tak tomu dají pokoj). Zde bych tedy radil oddíl (MRB nebo GPT, je to jedno).

Od jaké verze jádra považujete Btrfs za "dost dobře použitelné"?

3 roky. (Verzi nevím.)

Komprese asi není dobrý nápad. Jsou nějaké další věci, na které si dát pozor?

Komprese je dobrý nápad, pokud člověk ví jak pracuje. Je nesmysl ji používat na oddíl s nekomprimovatelnými daty a taky na oddíl se sice komprimovatelnými daty, ale s velmi malými soubory (menšími než je blok fs, obvykle 4kiB). Ideální by tedy byly textové soubory o velikostech od 1MB a větší . Neočekávejte ale rychlejší čtení dat, očekávejte úsporu místa.

Jak s defragmentací? Radši ruční než automatická? Jak často ji spouštět?

Dříve jsem to pouštěl z cronu jednou denně, teď mám autodefrag. Větších změn jsem si nevšiml.

Jaké procento zaplněnosti disku je podle vás v pohodě a kdy už byste běželi přidávat další disky?

Staré pravidlo říká 80% zaplněnosti, ono to spíše záleží na způsobu použití. Pokud bych měl na disku převážně velké soubory vzniklé jako reflink, které se postupně zaplňují, tak bych byl i u 50% nervózní. Ale disk se dá přidat vždy.

[Franta]

Dík za odpovědi, celkem jsi mě potěšil (někdy mě právě trochu znervózňuje nadávání některých lidí na Btrfs - já s tím mám právě taky dobré zkušenosti, ale zatím je to spíš testování a hraní si než nějaké uložení velkého objemu produkčních dat)

Teď si chci (až bude v geologicky dohledné době trochu víc času) pohrát se send / receive (zbavit se rsyncu) (viz http://www.heronovo.cz/dva-zpusoby-zalohovani-snapshotu-btrfs/). Co jsem zkoušel, tak to funguje dobře a rychle, ale dlouhodobější zkušenosti ještě nemám.

jj, jde mi hlavně o to send/receive, tedy zálohování na úrovni FS, ne na úrovni souborů - těch bude totiž hodně a budou malé, takže rsync by nebyl moc efektivní a zálohování by trvalo dlouho. Nejvíc mě na tom právě láká to, že FS bude vědět, co se od minule změnilo a při zálohování odešle jen ty změny a nebude se to muset znova kontrolovat soubor po souboru.

Staré pravidlo říká 80% zaplněnosti, ono to spíše záleží na způsobu použití. Pokud bych měl na disku převážně velké soubory vzniklé jako reflink, které se postupně zaplňují, tak bych byl i u 50% nervózní. Ale disk se dá přidat vždy.

Soubory budou malé a budou jich řádově tisíce (většinou jednotky tisíc nebo méně) v adresáři. Těch 80 % je v pohodě, s tím jsem tak nějak počítal, stejně je potřeba držet nějakou rezervu pro případný náhlý nárůst dat.

[Heron]

někdy mě právě trochu znervózňuje nadávání některých lidí na Btrfs

Kdyby se měl člověk řídit podle toho, na co lidé nadávají v diskusích, tak by nemohl použít nic . Kolem fs se vedou stejné flamy jako kolem vim / emacs, kde / gnome a intel / amd apod. Hlavně to chce zálohovat, ale to platí také pro každý fs. Btrfs je stále ve vývoji a je třeba s tím počítat. Ale podle mého názoru výhody převažují (a to mám i btrfs na rootu debianu, kde opravdu aptitude rychlostně moc nevyniká; jenže aptitude není to nejdůležitější na co ten počítač mám, že jo).

[Franta]

Hlavně to chce zálohovat, ale to platí také pro každý fs. Btrfs je stále ve vývoji a je třeba s tím počítat.

To je pravda, ale já právě zvažuji mít primární data na Btrfs a zálohovat taky na Btrfs pomocí Btrs nástrojů/vlastností...

[Heron]

Aha. Tak to bych nedoporučoval (ne k vůli btrfs samotnému, ale obecně), protože chyba v jedné technologii ti tak ohrozí všechna data. Záloha by se měla dávat někam úplně jinam.

[Franta]

Ono by to bylo úplně jinam (jiný server, jiné diskové pole, data odeslaná po SSH), ale stejná technologie resp. FS. Při zálohování z ext4 na ext4 by se nad tím asi nikdo nepozastavil, ne? Nebo bys taky radši zálohovat třeba XSF -> Ext4?

[Heron]

Nebo bys taky radši zálohovat třeba XSF -> Ext4?

Ano.

Ono to samozřejmně záleží na tom, jak dalece chceme nebo můžeme zajít. V naší firmě se servery zálohují (+ je tu ještě replikace) na zálohovací server a odtud ještě na pásku (data jsou tak min. na 4 místech, pásky se po čase uloží do trezoru a koupí se další), svoje soukromá data zálohuji na druhý server a ty důležitější mám ještě na externím mediu (takže všechno 2x, něco 3x). Krom toho mám ještě většinu dat v gitu, takže na více pracovních místech.

Byl bych velmi opatrný mít všechna data na jednom FS a to ještě k tomu na FS ve stavu vývoje (přestože jsem za 3 roky neměl s BTRFS žádný problém a nikdy nedošlo ke ztrátě dat).

[jadd]

Paní Carla, píše seriálový článek právě pro tebe. Ale nebudeš to mít vše hned. Prý jak budeš hodný.