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.
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.
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.
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.
Předpokládám, že dochází k fragmentaci - kopírují se jen změněné bloky. Nicméně na SSD to vůbec nevadí a rozhodně je lepší mít FS, který není vhodný pro jakékoliv použití, ale má řadu benefitů, než jenom samé "univerzální" FS, které se od sebe liší prakticky jen maximální velikostí a počtem souborů. ;-)
"Neviděl jsem však žádné reálné nasazení" - s nadšením používam na scratch disk - užívatelia si cez to vymieňajú v LAN dáta, beží na tom tmpreaper (životnosť dát pár dní), dáta nie sú dôležité, takže neodladenosti sa nebojím, a ak si tam niekto odloží jedinú verziu súboru a zabudne na ňu, dá sa k tomu vrátiť.
Potom to používam na záložnom serveri - rsync na nilfs je pohodlnejší než faubackup a ľahšie sa vracia k predchádzajúcemu stavu (ešte to nebolo treba).
Najviac mi chýba ACL.
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á.
Snapshoty moc nepomohou, to by chtělo transakce nebo alespoň něco jako Featherstitch, aby aplikace mohla lépe specifikovat, jaké pořadí operací je nutné pro zachování konzistence.
Resp. pokud se smíříte s tím, že vám „rollback“ uvede do původního stavu celý subvolume, nejen ty změny týkající se updatu, tak se i ty snapshoty použít dají.
Yum ve Fedoře plugin na snapshoty má, ale myslím, že to prostě jen na začátku udělá snapshot a na použití fsyncu to nemá žádný vliv a update to neurychlí (ale nezkoušel jsem to :-).
Dnes už mám Btrfs skoro 4 měsíce a ohledně rychlosti je čím dál horší :-\ Přičítám to fragmentaci způsobenou snapshotama (udržuju si cca 20 snapshotů, resp. měsíc dozadu). Zatím jsem to ale více nezkoumal, zejména proto, že defragmentace zničí COW a všechny soubory tak zduplikuje (čímž se trochu ztrácí výhoda snapshotů).
Btrfs zkus, ale zrovna rychlost od toho moc nečekej. Anebo udělej nějaké testy a dej sem vědět :-)
... 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 ....
Zajimalo by mne:
verze TSM
pocet zalohovanych souboru
velikost databaze
My doporucujeme 1 TSM server v5.3 na 30 GB databazi.
Sestku zakaznici moc nechteji, aby nemuseli preskolovat adminy. Pocitaji s tim ze ty stavajici vyhodi a vezmou novy co umeji TSM 6. Jo optimalizace nakladu v IT, pak zjisti ze novi lidi sice umi TSM6 ale nevyznaji se v tom bordelu co tam maji.
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_dulezita_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)
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 :)
Používám BTRFS asi půl roku pro celý OS na svém primárním NTB a jsem naprosto spokojený. Drobné potíže se občas vyskytnou - chce to mít co nejnovější kernel, ale jinak v pohodě. O žádná data jsem zatím nepřišel.
Hlavně tu nezazněla on-line defragmentace, což já osobně považuji za důležité, protože mým 64GB oddílem za měsíc proteče tak 100GB dat (hodně průběžných write-once zápisů a jednou za čas garbage-collect, viz NixOS).
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ě...