Btrfs nebude výchozí ve Fedoře 16

Josef Bacik oznamuje, že výchozím souborovým systémem pro Fedoru 16 nakonec zůstane ext4 a plánovaný přechod na btrfs se odkládá. Důvodem je nesplnění předsevzatých kritérií v termínu pro vydání Alpha, především co se týká fungujícího fsck. Z Josefovy zprávy je zjevné, jak ho otravují nejapné narážky, které lidé připisují do bugreportů o btrfs.

8.8.2011 17:35 | michich | Zajímavý článek

Komentáře

[Jiri]

Mam btrfs jiz nejakou dobu na notebooku. Jedine co me stve je problem s apt. Resi se to s eatmydata, ale neni to ono.

[Karry]

Přesně tak. S výchozími parametry se btrfs používat dá až na tem mizerný výkon při fsync, který hojně využívá například apt a NFS server. Stěžuje si na to spousta lidí, vývojáři si ale stojí za tím že oni implementovali fsync správně a moc lepší už to být nemůže.

To mě ale přivádí na myšlenku že ext* implementuje fsync špatně...?

[michich]

vývojáři si ale stojí za tím že oni implementovali fsync správně a moc lepší už to být nemůže.

Lepší to být může a snad i bude. K tomu napsal Josef Bacik:

Fsync _sucks_ for btrfs currently, and it has historically not been a well optimized piece of code. I'm working on fixing this, but it requires VFS level changes that are currently sitting in Al's queue. I suspect they will go into 3.1 and so we can move ahead with our work, but for now, it sucks. [...]

[Heron]

Tohle už se řešilo několikrát. Volání fsync na systém souborů má za úkol vyprázdnit cache a vše nezapsané zapsat na disk. Pokud někdo volá fsync v případě, že potřebuje syncnout pouze jeden soubor, tak to volá špatné (ten soubor si může otevřít v jiném režimu). Stejně tak, pokud někdo potřebuje mít data na disku a místo fsync volá přejmenování adresáře (případ ext4 a ztrácejích se konfiguráků), tak je to též špatně.

Ext4 zavedla nějakou heuristiku, která má poznat co vlastně aplikace chce udělat.

Ono navíc u btrfs je nutné pro každou změnu souboru alokovat další bloky (copy on write), takže výkon neustálého přepisování jednoho souboru jde logiky do kytek. Což mě zatím docela mrzí, protože PostgreSQL mi na ext4 na raid5 (pro DB fuj) jede výrazně rychleji, než na BTRFS. Což není výtka, to je prostě fakt.

[Ondrej 'SanTiago' Zajicek]

On hlavne je problem v tom, ze existujici API nenabizi to, co by programy potrebovaly. Takze to aplikace at uz jednim (pouzivaji vyrazne silnejsi a 'drazsi' nastroje jaky fsync nebo O_SYNC) nebo druhym zpusobem (pouzivaji neportabilni triky) obchazeji. A oba ty workaroundy jsou na pytel.

Tipuju, ze prevazna cast programu ve skutecnosti nepotrebuje zajistit, aby data byla skutecne na disku, ale spis potrebuje vytvorit 'synchronizacni bod' (tedy aby stav na disku presel z jednoho konzistentniho stavu do druheho konzistentniho (ale ne nutne ted), takze pripadny vypadek by zpusobil navrat k predchozimu konzistentnimu stavu a ne nejaky uplne nekonzistentni stav). To je zrovna pozadavek, ktery by (AFAIK) btrfs mohl implementovat asi vcelku snadno vez vetsiho overheadu.

[Heron]

To API existuje. Akorát ne u FS. Tam ani nepatří.

[Ondrej 'SanTiago' Zajicek]

A proc by tam nepatrilo? Kdyz ho programy potrebuji. Je nesmysl, aby takovou zakladni funkcionalitu si musel kazdy zajistovat sam (nebo naopak zas na vsechno pouzivat databaze).

[Heron]

Přechod z jednoho konzistentního stavu do druhého u vícero souborů lze zajistit pouze pomocí transakce a její (jejich) izolace. Případně verzováním. Zajistit si verzování, pokud to je skutečně potřeba, zvládne každý programátor sám.

Zajistit na FS podporu transakcí pro více souborů je složitější.

Pokud si to programátor nechce psát sám, ano, má tu DB. Nevidím problém na toto klidně nějakou použít.

[Petr Tomášek]

u vícero souborů

Ten problém ale je i jen u jednoho souboru. Tam opravdu nevidím důvod, proč by nešlo udělat API tak, aby program mohl vytvořit nový soubor a atomickou operací jím nahradit obsah staré verze souboru. Databáze jsou na tohle skutečně overkill...

[Heron]

Jde. fsync.

btrfs by tohle mělo zajištovat by default. Buď je tam konzistentní stará verze (starý poslední zápis), nebo nová. Jenže když do jednoho souboru udělám 3x zápis (které spolu souvisejí) na ruzná místa, tak můžu stále získat nekonzistentní soubor.

Já jen upozorním, že toto všecho se týká stavu po špinavém odpojení fs (pád systému / výpadek napájení). Myslím si, že by se především mělo řešit tohle nečisté odpojení, pak zálohy a až někdy bude čas, tak se hádat o tom, co má přesně zůstat na FS poté, co se všechno pokazí. POSIX tohle neobsahuje.

[Ondrej 'SanTiago' Zajicek]

Jde. fsync.

fsync je overkill.

[Heron]

Prosím uložte nám data na disk bezpečně tak, aby jste na disk nic nezapsali a přežilo to výpadek napájení.

Pokud chcete data na disku, musite je tam zapsat. Pokud je tam chcete zapsat, musí k tomu být všechny souvislosti (metadata). Této operaci se říká fsync.

Ano, fsync je pomalý, protože je pomalý disk pod tím.

Já bych jen rád upozornil na to, že pokud někdo nechce čekat na fsync, ale chce ho provést, tak ta data může zapisovat v jiném vlákně. Asynchronní přístup, tuto brutální novinku lidstvo vymyslelo už dávno.

[Ondrej 'SanTiago' Zajicek]

Já bych jen rád upozornil na to, že pokud někdo nechce čekat na fsync, ale chce ho provést, tak ta data může zapisovat v jiném vlákně. Asynchronní přístup,

Jenze ten fsync nezpomaluje pouze ten cekajici program, ale system celkove (tim ze vytvari zbytecne pozadavky na diskovy subsystem), zvlaste pak na implementacich, ktere implementuji fsync() vicemene stejne jako sync() (AFAIK pripad ext3/4). Proto je reseni s fsync() v pripadech, kdy neni pozadovano, aby data byla skutecne zapsana na disk, ale je pozadovano jen vhodne relativni usporadani operaci, nevhodny overkill.

[petr_p]

Mícháte dva požadavky dohromady: uspořádání za běhu a po resetu. Na první je fsync opravdu zbytečný, protože viditelnost změn pro uživatelský prostor zaručuje dokončení systémového volání. Pokud jde o reset, tak tam si jinak než skutečným zápisem, tedy fsync(), nepomůžete.

Vyvozovat z nějaké implementace, že fsync je pomalý, je celé trapné. Od toho ostatně máme konkurenční souborové systémy. Třeba btrfs, který je ještě pomalejší :)

[Ondrej 'SanTiago' Zajicek]

Nemicham. O usporadani za behu nemluvim. Mluvim o situaci po nahodnem restartu. Pro zajisteni konzistence (nikoliv zachovani vsech dat) opravdu skutecny zapis nepotrebuji, akorat staci, aby si FS zapamatoval, ze nektere operace je treba udelat v urcitem poradi (ale je mi jedno kdy, zda ted nebo treba za hodinu).

Vyvozovat z nějaké implementace, že fsync je pomalý, je celé trapné.

No, pokud nekdo programuje pro hypoteticky obecny POSIXovy system, pak mu to mozna je jedno, ale to je asi stejne smysluplna cinnost jako programovani pro genericky turinguv stroj. To, jak efektivne program pobezi v realnych podminkach je proste dulezity parametr.

[Heron]

opravdu skutecny zapis nepotrebuji, akorat staci, aby si FS zapamatoval

Pravda. FS to nemusí zapisovat, stačí, když si to zapamatuje.

Toto zajištuje žurnálování. Některé FS (ty "pomalejší" - proč asi) umí ordered (nebo dokonce žurnálování dat). Tam je zajištěno pořadí. Opakuji jen některé a jen při konkrétním nastavení.

Aneb proč řešit věci jednoduše, když to jde složitě, že. Buď si ten zápis, který nutný je, obstrarám sám, nebo (zcela v UNIXovém duchu) o to požádám nějakou knihovnu, která je na to specializovaná.

[petr_p]

Jenže souborový systém nemůže čmuchat, které operace to jsou. To ví jen aplikace. A proto tu máme fsync(), kterým aplikace řekne, že aktuální stav daného souboru je onen konzistentní stav.

Ano, máte pravdu, že by jej stačilo považovat za bariéru (na daném i-uzlu) a zápis odložit na později. Jenže problém je, že tím stále nemáte řešenou synchronizaci mezi více (fsyncnutými) soubory. To by se vyřešilo zachováním pořadí fsync() bariér, nicméně to pak rovnou můžeme nasadit UFS (kdyby Linux na něj uměl zapisovat). Jinak problém je to zajímavý a postupné zaváděníní volání f*() a *_at() ukazuje, že o transakce je zájem.

[Ondrej 'SanTiago' Zajicek]

Jenže souborový systém nemůže čmuchat, které operace to jsou. To ví jen aplikace. A proto tu máme fsync(), kterým aplikace řekne, že aktuální stav daného souboru je onen konzistentní stav.

Jenze hlavni problem fsync() je v tom, ze dela mnohem vic nez jenom tohle - fsync v prve rade rika, ze se maji flushnout modifikovana data a metadata na disk, coz je principielne draha operace a neco, cemu by se jak uzivatele tak programatori radi vyhnuli. Resenim by bylo zavedenim nejake vyrazne slabsiho volani (nazveme ho treba fbarrier()), ktere by melo vyznam (vhodne definovane) bariery, aniz by vynucovalo vcasnou synchronizaci.

No a soucasna situace v Linuxu je zda se takova, ze neni moc zajem zavadet nove syscally (nebot stavajici programy se moc nenamahaji je nasadit) a spis tyhle situace vyresit zavedenim vhodnych idiomu (ktere uz stavajici aplikace vice-mene vyuzivaji), kterym by rozumelo stejne jak jadro tak programy.

[Heron]

Resenim by bylo zavedenim nejake vyrazne slabsiho volani (nazveme ho treba fbarrier()), ktere by melo vyznam (vhodne definovane) bariery, aniz by vynucovalo vcasnou synchronizaci.

Řešením by bylo, kdyby se pro daný problém používaly věci pro to určené na místo změny věcí, které by měly být stabilní. Řešení existuje. Chtít změnit jádro pro případ, který si userspace aplikace může velice dobře a levně ošetřit sama či s pomocí dobře známých knihoven, není nejlepší způsob řešení.

[Petr Tomášek]

Jo? A jak zajistím, aby mi nesyncnul soubor někdo ještě předtím, než do něj zapíšu všechna data...?

[Heron]

???

Souborový systém zapisuje data na disk tak, jak se mu hodí (či spíše dochází paměť na špinavé stránky). Takže zápis souboru na disk typicky probíhá ještě během zápisu aplikací. Důležitý je ten sync až za uzavřením souboru.

Důležité je si uvědomit, že souborový systém se stará o konzistenci metadat. Konzistence dat souborů až na výjimky zajištěna není (některé fs tam nechají garbage, jiné nuly). Pokud je opravdu vyžadován stav souboru 1 nebo stav 2, ale nic mezi tím, není jiná možnost, než použít transakční izolace.

Zkrátka chcete po souborovém systému něco, na co nebyl navržen.

[Petr Tomášek]

Zkrátka chcete po souborovém systému něco, na co nebyl navržen.

Ano a to je špatně, protože potřeba požadavek na atomické přepsání souboru novým obsahem je tak elementární záležitostí, že by na to prostě nějaké API existovat mělo.

[petr_p]

rename() (a mašinerie chmod(), chown(), utime(), setfattr()). Otázka ale je, co je to soubor. Jestli jde o název nebo i-uzel.

[Petr Tomášek]

No, právěže s rename() jsou nějaký problémy, tuším právě u btrfs je tam nějaká race-condition a není to bug, ale feature...

[Heron]

Trik s rename fungoval jen a pouze štastnou shodou náhod.

Souborový systém ext3 měl standardní nastavení ordered journal. A taky automatický commit (fsync) každých 5s. Ordered znamená, že se nejdříve zapíší data a až pak metadata. rename je změna metadat. Tedy, aby bylo možné toto fsyncnout (těch automatických 5s), tak se na disk uložila data a až pak metadata.

Aplikace nalila do souboru data, udělala rename, to všechno velmi rychle, a za nejdéle 5s to bylo na disku. Program nemusel čekat.

Toto jinde nefunguje a na ext3 v jiném nastavení taky ne. Jen to jen náhoda a nikde není dokumentováno, že toto by se mělo dělat. V ext4, díky delayled alocation, to také nefunguje. Tam se dával nějaký patche do jádra zjištující, co vlastně programátor tím rename chtěl říct.

Proto jsem psal o tom asynchronním vlákně pro zápis. V podstatě se ti simuluje stejné chování a to na všech fs a za všech nastavení. Není možné se spoléhat na konrétní fs.

[petr_p]

Reagoval jsem na:

aby program mohl vytvořit nový soubor a atomickou operací jím nahradit obsah staré verze souboru

A to rename() splňuje z definice. Pokud tomu tak není, pak se nejedná o posixový souborový systém a je to problém uživatele (asi jako by použil VFAT a divil se, že nemá symlinky).

Pokud se řeší obsah po resetu, tak stačí zavolat fsync(), protože ten (alespoň na Linuxu) zaručuje zápis i metadat (rozdíl proti fdatasync()).

Jinak řečeno se nejedná o shodu náhod, ale o jasně definovanou vlastnost.

Co se řešilo v ext*, bylo, že někdo raději rychlejší systém, a tak výše uvedenou definici ignoroval (distributor vypnul ordered režim), což mělo za následek, že se ozvali lidi, kterým tato „optimalize“ rozbila systém, a tak se hledal kompromis, což vyústilo v heuristiku při neordered režimu.

[Ondrej 'SanTiago' Zajicek]

Podle Btrfs FAQ prave btrfs potrebnou atomicitu rename pri prepisu (resp. synchronizaci s predchozim zapisem dat) zajistuje: What are the crash guarantees of overwrite-by-rename?.

[Petr Tomášek]

Ano a podívejte se následující sekci. Jestliže:

echo "content" > file.tmp
mv file.tmp file

# *crash*

will most likely give you a zero-length "file".

pak je něco špatně...

[Heron]

Ano je, chybí tam ten sync, co je v příkladu výše.

[Petr Tomášek]

Toho jsem si pochopitelně všimnul, jenže popsané chování nedává (z hlediska uživatele) smysl.

[Ondrej 'SanTiago' Zajicek]

No, bylo by asi lepsi, kdyby to dalo zero-length "file.tmp", ale narozdil od pripadu s prepisem existujiciho souboru me prijde, ze tohle neni idiom, ktery by byl nejak casto vyuzivan, a jehoz naruseni by neco vazne rozbilo.

[Ondrej 'SanTiago' Zajicek]

Jo, jenze pro 95 % programu by uplne stacilo, kdyby to fungovalo konzistentne v ramci jednoho souboru. Tedy typicky by nebylo treba resit transakce a spol, ale stacilo by mit neco jako soft updates - zajistit, ze metadata se budou updatovat az pote, co dojde k updatovani dat.

[Heron]

To u extX funguje a jmenuje se to ordered journal a dokonce je to default. Některé FS toto vůbec nemají a je potřeba s tím počítat. Nelze se spoléhat na konkrtétní nastavení konktérního fs.

[rajo AT platon.sk]

Ako som vyskusal Btrfs