Btrfs jako standardní souborový systém ve Fedoře 16 (diskuse)

[Jan Holosko]

V com su take vyhody toho FS oproti napr. JFS ci XFS? Ja nijake nevidim...

[andree]

http://superuser.com/questions/141215/what-advantages-of-btrfs-will-a-normal-user-notice

napr. copy-on-write by nemusela byt zla featura (hlavne v spojeni s SSD diskom)...

[Mordae]

Snapshoty: je mozne delat periodicke snapshoty homu, snapshoty rootu pri kazde yumove transakci atd.. Snapshot je mozne udelat nad jakymkoliv adresarem a pridavnym parametrem je mozne mountnout subvolume (snapshot).

Copy-on-write kopirovani souboru: cp --reflink=auto umoznuje udelat kopii souboru, kterou je mozne neomezene menit, aniz by se toto dotklo puvodniho souboru a pouze rozdil mezi nimi skonci na disku. Takze v praxi napriklad na snapshoty virtualnich disku, ci jinych velkych souboru.

Bezproblemove zmeny velikosti: je mozne btrfs podle potreby resizeovat, nahoru i dolu. A to i online.

[kavol]

jo, to dělám naprosto běžně, každej den milionkrát ...

co takhle výkon?

kromě siláckejch řečí, jak je to jak blesk ... to byl reiser4 taky, po chvíli používání a zaplnění disku na 90% čekám věky ...

co spolehlivost při výpadcích, to to opravdu "nepotřebuje"(*) fsck?

(*) dle fedořích kriterií potřebuje, mluvím o tom, že se to nikdo nenamáhal řešit dřív

[Viktor]

Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready.

[Heron]

O tomhle už mluvil Andrej, jako o jediném známém případu poškození BTRFS.

Takové disky patří výrobcům omlátit o hlavu, a ně pro ně dělat podporu ve FS.

(Tím nezpochybňuji potřebu fsck.)

[kavol]

Takové disky patří výrobcům omlátit o hlavu, a ně pro ně dělat podporu ve FS.

hele, asi nechápu, co znamená "handle flush requests correctly", nicméně přijde mi, že disk má docela "právo" pokundit data, přijde-li o napájení během zápisu ...

[Heron]

Snapshoty jsou vysoce použitelné. Proto jsem BTRFS nasadil, i když ještě není stable. Pokud tě to zajímá, tak snapshoty dělám každou hodinu v cronu (jako takový timemachine) a před každou důležitou operací. Ono když si místo kopírování stovek giga dat (což trvá) uděláš v průhěhu dané operace několik snaphotů (které jsou už z povahy BTRFS velmi levné), tak na hlavní featuru tohoto FS přijdeš sám. Na disku to nic nezabírá a pokud něco nevyjde, tak se prostě namountuje nějaký dřívější snapshot a jede se dál.

Ad výkon, má to příkazy rebalance a defragment, takže se výkon na svazku dá získat zpět. Tyto údržbové operace to potřebuje už jen z důvodu COW funkcionality.

fsck by to díky COW potřebovat nikdy němelo, ale offline kontrola by se jistě hodila.

[Käyttäjä 11133]

COW? O jéje, to musí být děsně rychlé při hromadě snapshotů... :)

[JoHnY2]

Pokud vim (a mozna vim blbe), tak Btrfs vazne nema rado uplne plny partitiony, nejspis este vic nez reiser4. Copy-On-Write file system se nikdy neposkodi sam, musi mu k tomu pomoct HW nebo pripadne hodne blbej bug (ty uz btrfs snad nejakej patek nema). Fsck samozrejme potreba je, protoze poskozeni muze vznikat ledajak a jeho zdroj nemusi mit v FS nic spolecnyho.

[tomboytom-deviant]

Ty snapshoty a vse okolo nich, to je muj sen

[imploder]

+1

[Radovan Garabík]

Ja práve preto používam nilfs2 - ale len na záložnom serveri.

[Radek Hladik]

Teda musím uznat, že se Fedora docela rozjela :) Osobně bych byl are rád, kdyby i další takovéhle masakr změny byly v 16ce v režimu "defaultní volba, ale klidně si dejte, co chcete". Fedoru používám i na serverech (důvody se tu už kolikrát řešily), takže občas potřebuju nějakou "konzervativnější" verzi. V 15ce je systemd, který v 16ce bude tak akorát k použití, takže to vychází ob verzi, což je ideální.

[hydrandt]

Zaujal mě nárůst výkonu při použití té nové komprese, kterou je možno použít od 2.6.38 -- viděl jsem nějaký test na Phoronixu a rozdíly mezi žádná-ta starší-nová komprese byly dost velké. Máte s tím někdo praktické zkušenosti?

[JoHnY2]

S kompresi bych byl opatrnej. Jsou mista kde prospiva, ale podobne jako sifrovani (i kdyz v mensi mire) svazuje diskovy operace s dostupnosti volnyho procesorovyho casu. Obecne to muze i pomoct, ale kdyz mas komplexni zatez, ktera zere CPU, ramku i k tomu zivelne zapisuje na disk, tak to muze i solidne brzdit.

Pametnici si jiste zive pamatujou jak obrovskej rozdil byl mezi DMA a PIO modem u PATA disku i kdyz prenosovka mela bejt teoreticky stejna.

[hydrandt]

Díky za reakci, asi to stejně zkusím - zjevně nikdo praktické zkušenosti nemá

[Ubunt0r]

Bude neco podobneho dostupne i pro OS Ubuntu_?

[Matlák]

[clayman]

Ale no tak.

Pro tazatele: Ubuntu je linuxová distribuce stejně jako Fedora, takže v zásadě stačí, aby Canonical (společnost stojící za Ubuntu) povolila možnost použití Btrfs a neměl bys problém. Zatím je ale Btrfs stále příliš nový filesystem a vzhledem k absentujícímu nástroji na jeho opravu by jakákoliv restaurace poškozeného filesystemu byla nad síly typického uživatele, na kterého je distribuce typu Ubuntu cílena.

[Bedňa]

Rozbitý filesystém bez nástrojov na opravu, nespravý určite ani Debianista a ani 99.9% ľudí na zemi. V Ubuntu je zas ReiserFS čo je zatiaľ stále lepšia voľba.

[l4m4]

Nj, proč taky uživatelům strkat nedostatečně otestovaný filesystém, který s určitou, byť velmi nízkou pravděpodobností povede k problémüm, když můžeme překopat celé GUI a tím problémy zajistit pro každého.

[clayman]

To už je z trochu jiného soudku... O přínosu prostředí Unity nehodlám spekulovat ani polemizovat, ale myslím si, že změněné GUI je _imho_ stále řádově menší problém než dokopaný souborový systém.