Revoluční změna ve Fedoře schválena

12.6.2011 09:23 | Přečteno: 1489× | poslední úprava: 12.6.2011 09:22

FESC rozhodla, že standardním souborovým systémem ve Fedoře 17, ale možná už ve Fedoře 16 se stane skvělý Btrfs.

Skvělý Btrfs je od roku 2007 zatím stále ve vývoji, o zařazení do Fedory rozhodne skutečnost, zda již konečně bude podporovat něco jako velmi potřebný fsck.

Btrfs je šířen pod licencí GNU GPL a je již zařazen v linuxovém jádře od verze 2.6.29-rc1. Přináší některé výborné vlastnosti systému ZFS od Sunu, který je licencován pod CDDL.

Základní vlastnosti
Maximální velikost souboru 2^64
Efektivní způsob ukládání krátkých souborů
Efektivní způsob indexování direktorářů
Dynamicky alokované inody
Zapisovatelné snapshoty
Podsvazky
RAID 0 (striping), 1 (mirroring) a 10 (1+0)
Kontrolní součet dat a metadat
Kontrola systému za běhu
Velmi rychlá kontrola systému offline
Efektivní inkrementální zálohy
Skvělé další stávající a připravované vlastnosti

O souborovém systému Btfrs již před několika lety abc přineslo tento výborný článek od Jirky Bourka.

       

Komentáře

[Migi]

eeeeeeeeeeehm http://www.abclinuxu.cz/zpravicky/btrfs-jako-standardni-souborovy-system-ve-fedore-16

[Rezza]

Zadna FESC neexistuje, je to FESCo - Fedora Engineering Steering Committee. Zatim je schvalena jen featura, nemusi se ale do F16 dostat, pokud se ukaze, ze to jeste neni ready. Jinak to bude jen cista nahrada ext4 za brtfs. Pod tim bude zase LVM atd., tudiz nebude to vyuzivat vseho, co brtfs umi nativne. To bude chtit asi jeste nekolik verzi Fedory - upravy v Anakonde, tooly k tomu systemove atd. Jo a Marcelinu +1 pro ext4->brtfs bylo ve skutecnosti pro doplnujici otazky na autora featury :D

[Sten]

Snad kvůli tomu vyvinou konečně ten fsck. btrfs se mi moc líbí, ale zrovna včera se mi rozpadl kvůli tomu, že jsem během aktualizace systému ten systém hibernoval. fsck.btrfs pouze konstatoval, že systém je rozbitý, a read/write mount skončil nekonečnou smyčkou v jádře (read-only mount naštěstí fungoval a všechno kromě asi deseti souborů se dalo přečíst). Takže zatím jsem se vrátil k ext4.

[Michal2]

Vlastnosti ma super... ale stoji to za takovy propad vykonu? Neprijemne dilema.

[Heron]

Jaký takový?

Výkonnostní propad jsem zaznamenal pouze u PostgreSQL testu, kde to má ale zcela jasné příčiny. Běžné souborové operace jsou řekl bych standardně rychlé (tj. rychlostí disku) o +-10% se hádat nehodlám.

Až na ten PostgreSQL (což by šlo snad obejít namountování daného svazku s volbou nocow, zatím jsem to nezkoušel) jsem ve výkonu mezi BTRFS a XFS nezaznamenal větší rozdíl.

Naopak to má pro mě naprosto killer featuru v podobě snapshotů.

[LukynZ]

A uz opravili tu nechutnou fragmentaci a nechutnou rezervaci volneho mista?

[Heron]

Co tím přesně myšlíš?

[=^..^= AmigaPower®]

...nechutnou fragmentaci a nechutnou rezervaci volneho mista?

[Heron]

Tak to je nechutný

[Mandarinka]

Heh, možná to byla reakce na ty divné superlativy v blogpostu :)

Výborné brtfs... Že by epiteton constans?

[LukynZ]

Tim myslim, ze btrfs hezky fragmentuje (alespon kdyz jsem to zkousel a to zas tak moc davno neni, jeste zacatkem tohoto roku jsem ho mel). Napriklad na gentoo po 14ti dnech trval sync portage klidne i 5 minut a procesor pekne makal (vse nejake veci okolo btrfs), jedine reseni bylo smazat celou portage slozku a syncnout ji nacisto znovu, pak to zas jelo v pohode, ovsem za cca 14 dni (podle toho jak syncoval casto) mohlo mazat znovu a celkove se system s updatama za ty 3 mesice co jsem to mel docela zbrzdoval.

Dalsi vec, co jsem nezminil, byla situace, kdy dosla ram a melo se swapovat. To btrfs kilnulo cely pocitac a procesor teda dostal zahul.

A s tim mistem - no treba ma 260GB vykazovala rekneme 100GB zabraneho mista a 100GB volneho (kde je tech 40?). Co jsem se pak docetl, tak se jedna o nejakou rezervaci filesystemem a kazdy to nejak ma. Dal jsem po tom nepatral, protoze uz jsem stejne mel v planu prejit zpet na ext4 a musim rict, diky bohu za to, protoze oproti btrfs to beha naprosto bez problemu a rychle.

[Heron]

Už z principu COW to fragmentuje. Jinak se to dělat nedá. BTRFS má v základu příkazy btrfs filesystem defrag a btrfs filesystem balance. Ty bude potřeba na klasických diskách prostě občas spustit (rebalance pomůže i volnému místu). Na SSD (až bude uveden jako stable, tak už SSD budou rozšířené), to tak kritické není. Holt je to vyšší liga a potřebuje jistou péči.

Ad pád systému, no BTRFS ovladač je stále ve stavu experimental.

Ad místo na disku. Přístupů k tomu je víc. btrfs filesystem df; df; du - všechny ukáží jiné volné / zabrbané místo. Zaleží na úhlu pohledu.

Jenom pro příklad:

#btrfs fi df
Metadata, RAID1: total=7.25GB, used=2.97GB
Data, RAID1: total=419.00GB, used=334.33GB
System, RAID1: total=8.00MB, used=76.00KB
System: total=4.00MB, used=0.00

# df -h /workspace
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb3             1.9T  338G  1.5T  19% /workspace

Obé vyžaduje znalosti k pochopení. BTRFS ukazuje total 419GB, což není velikost úložiště, ale pouze údaj, kolik místa zatím alokoval. DF ukazuje velikost úložiště 2TB, což ale také není správně, protože na v rámci btrfs mám raid1 na data. Správně je 1TB. I used se liší (se divím, že tak málo). Na tom FS mám něco kolem tisíce snapshotů. Je to dost tricky -- takže v podstatě jedniní, co po tom fs chci je, aby mi včas oznámil, že mu mám přidat další dva disky.

To co zmiňuješ ty je možná místo rezervované pro roota, které mají i ext a ve výchozím stavu je to 5%.

[xkucf03]

v rámci btrfs mám raid1 na data. Správně je 1TB.

Co potom ukazuje du na jeden soubor? Jeho skutečnou velikost nebo dvojnásobek, protože je na disku díky RAIDu dvakrát? Nemělo by se od toho abstrahovat -- jedna vrstva řeší RAID a na vyšších vrstvách mne to už nezajímá a chci znát raději skutečné velikosti souborů (ve smyslu: kolik bajtů z toho souboru můžu přečíst)?

[Heron]

du na jeden soubor ukazuje správně jeho velikost. Tedy i bez ohledu na kompresi atd. Problém nastane u du na více souborů (nebo celý fs). Soubory vzniklé jako reflinky bere jako dva nezávislé soubory (i když reálně mají většinu bloků společných) a snapshoty jako zcela oddělené adresáře (což de facto jsou, ale soubory sdílejí své bloky). Tedy du ukazuje obecně více, než je ve skutečnosti (na úrovni bloků) zabráno.

[pozortucnak]

Hmm hezký, btrfs filesystem defrag a btrfs filesystem balance mi nedávno vyřadil systém na cca 40 hodin... (500GB oddíl)

[sam]

"direktorářů" - uff, takovej patvar se jak dlouho vymsli?
osobne nemam problem s pouzivanim cizojazycnych vyrazu, ale podobne silene kolomeniny jsou jak dezen po skonzervovani obeda ...

[krasny13]

Na direktoráře si pamatuju ještě z Amigy 500, a to už je nějakých let...

[=^..^= AmigaPower®]

Já teda ne, abych pravdu řek, ani netušim co to je

[kotyz]

Jestli von nemyslí adresáře ...

[krasny13]

Pokud se nepletu, někdo počeštil slovo directory. A někde je dodnes tlačítko OK na dialogu pojmenováno Budiž...

[kotyz]

Jo, to je v Gnome a GTK aplikacich, ale asi ne ve všech. Mohlo to bejt horší, mohlo tam bejt taky třeba "Staniž se"

[=^..^= AmigaPower®]

Nebo "pochválen buď pan ježíš kristus"

[AsciiWolf]

[Honz]

Podpálen buď Ježíš Cirkus...

[Aldagautr]

spis "dejštopánbů"

[Mandarinka]

"Budiž" se mi vždycky líbilo. Cancel mohlo být "Zadrž!", wait "pozhov". Daemony bych přejmenoval na pacholky nebo děvky :)

[=^..^= AmigaPower®]

"Partitióny", případně "pártyšny" byly taky dobrý, já snad vyndám Amiga Review a začnu lovit perly...

[xkucf03]

+1, taky jsem si říkal WTF? Prostě složka, adresář nebo třeba priečinok. Ale proč proboha někdo vymýšlí takový zrůdný patvar jako je "direktorář"?

[zxtlpn]

Nevím...

[Vskutečnosti Saýc]

Viva la revolucion!