Vlákno názorů k článku Souborový systém Btrfs: vlastnosti a výhody moderního ukládání dat od jaromrax - Zdravim, na zacatku v prehledu systemu mate za...
-
Zdravim, na zacatku v prehledu systemu mate za sebou 2x ext3, asi tam melo byt 1x ext3 1x ext4.
Docela bych ocenil takovou pripadovou studii: mam ext4 a ted dam btrfs. Co mi to prinese v pripade napr. desktopu a notebooku? Zalohovat musim tam i tam, zpatky v case se nevracim, bo pouzivam git, zvetsit/zmensit ext4 umim. Ukol by stal - ukazat, ze je tam neco, co jeste nevim, ze nutne potrebuju.
Kdysi (mozna i ted) se hodne pouzivalo LVM, ale neprisel jsem tomu na chut. Existuje to jeste, ma to co rict k nekterym vlastnostem brtfs?
Diky -
Co třeba - chci otestovat balík, jehož instalace do systému zanese spoustu bordelu a ne tak úplně mu věřím.
Snapshot, instalace, rollback - bez bordelu v systému?
To samé v případě upgradu - něco se rozbije, existuje jednoduchá bezbolestná cesta zpět.
Takhle mi to alespoň funguje u ZFS. Btrfs jsem párkrát zkoušel, jednou jsem přišel o data, pak jsem už díky zálohám při následujících pádech o nic nepřišel, ale do produkce to mělo daleko. Možná už je to bezpředmětný, ale ztracená důvěra se těžko získává zpět...
-
Na tohle to funguje skvele, problem nastane, kdyz ten system chces updatovat. Vypnuti sync (fsync) je u balickovaciho systemu skoro nutnost (o pripadny problem a rollback by se ti mel teoreticky postarat fs). Skoro si rikam, jestli by na tomhle principu nemel fungovat cely balickovaci system - proste si nestahnes balicek x, ale kompletni subvolume/snapshot toho balicku, ten se umisti do slozky a hotovo. Upgrade bude fungovat tak, ze se proste nahreje jiny snapshot a pokud se budes chtit vratit k predchozi verzi, tak to proste jednoduse prepnes zpatky.
-
Přesně na tomto pracuje Lennart Poettering: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
-
LVM se pouziva samozrejme i ted ;-) napr. *buntu/Mint a myslim i Debian ho pouzijou automaticky, kdyz se zvoli "sifrovani disku", nebo ho pri instalaci muze vybrat rucne uzivatel i kdyz nechce sifrovat....
pouzivam LVM vsude spoustu let, vyhoda je:
- neni treba hejbat oddilama kdyz chci nejaky zmenit
- zvetsit oddil lze za behu systemu i kdyz jde o systemovej a/nebo pripojenej oddil
- v LVM VolumeGroup nechat volne nevyuzte misto ktere lze podle potreby pridat stavajicim oddilum, nebo vytvorit docasne dalsi oddil
- lze pouzit snapshot, udelat zmenu v systemu, vyzkouset nejakou neoverenou instalaci balicku a kdyz bude problem, vratit zpet ("akorat" to neni stavene na vetsi mnozstvi snapshotu jako btrfs)
- pri pouziti sifrovani (LUKS) se s LVM odemknou vsechny oddily v LVM, pri sifrovanych beznych Ne-LVM oddilu se musi kazdej odemknout sam (pokud ty to bylo naopak chtele, lze udelat LVM primo na disk a LVM az na vybranejch LV oddilech) -
- v LVM VolumeGroup nechat volne nevyuzte misto ktere lze podle potreby pridat stavajicim oddilum, nebo vytvorit docasne dalsi oddil
A právě tohle mi na LVM vadí. Ta NUTNOST nechávat nevyužité místo. Nemožnost jednoduše jedním příkazem, trvajícím zlomek sekundy, zmenšit jeden filesystém a ihned to přidělit pro jiný fs ze stejného VolumeGroup.
V ZFS je v poolu místo sdílené přes všechny filesystémy, pokud není nastaveno jinak (quota, rezervace). Na to, abych si vytvoříl nějaký dočasný filesystém, si nic nemusím extra rezervovat.
-
Já čekám na tu podporu Raid 5 v btrfs, aktuální use case:
- mám 4x2G disky v MD Raid 5, na tom mám GPT + ext4
- pokud chci přidat disk, tak musí mít 2G, a musí se provést kompletní rehash celého diskového pole
- pokud chci změnit velikost disku, musím vyměnit všechny disky
- pokud bych tam měl btrfs, budu moct přidat disk libovolné velikosti, přeskládají se pouze data, která jsou potřeba, a stále mi zůstane výhoda Raid5, že může bez ztráty dat havarovat libovolný disk.
- oproti tomu u ZFS existující vdev rozšířit vůbec nemůžu, můžu jen přidat další vdev, ale zase ztrácím redundanci, nebo můžu nahradit všechny disky většími+expand, ale to jsem tam kde jsem byl s MD
