Jaderné noviny – 9. 6. 2011: Podpora snímků v ext4

20. 6. 2011 | Jirka Bourek

Články - Jaderné noviny – 9. 6. 2011: Podpora snímků v ext4  

Aktuální verze jádra: 3.0-rc2. Citáty týdne: Al Viro, Ingo Molnár. Problémy se snímky v ext4. O vsyscallech a vDSO.

Obsah

• Aktuální verze jádra: 3.0-rc2
• Citáty týdne: Al Viro, Ingo Molnár
• Problémy se snímky v ext4
• O vsyscallech a vDSO

Aktuální verze jádra: 3.0-rc2

Současné vývojové jádro je 3.0-rc2 vydané 6. června. Byl relativní klid, i když aktualizace btrfs je o něco větší, než jsem doufal. Krom toho se jedná hlavně o opravy ovladačů, nějaké aktualizace ubifs a několik revertů regresí. Zkrácený changelog je v oznámení, detaily najdete v kompletním changelogu.

Stabilní aktualizace: v tomto týdnu žádné nevyšly a žádné se ani v době psaní tohoto článku nerevidují.

Citáty týdne: Al Viro, Ingo Molnár

Chyby jsou jako houby – když nějakou najdete, porozhlédněte se po dalších...

-- Al Viro

Maximalizace bezpečnosti je obtížná: jestli má chyba bezpečnostní dopady značně závisí na chybě a na způsobu nasazení a ve většině případů není bezpečnostní dopad chyb odhalen. Odhaduji, že v KAŽDÉM OS je pravděpodobně desetkrát víc chyb s potenciálním bezpečnostním dopadem, než kolika se kdy přiřadí CVE číslo...

Vkládání CVE do changelogu je tedy škodlivé, zbytečné, zavádějící a jenom by to vytvořilo falešný průmysl „vyděsit uživatele“ a „získat pozornost“ (společně s aspektem „dlouhou dobu zdržovat opravy chyb“, když to bude dobře zaplacené), který by operoval na přiřazování CVE čísel a jejich 'řešení' – to demotivuje skutečné opravy chyb a lidi, kteří se sami nezvolili opravovateli chyb.

Rád bych posílil přirozený průmysl 'opravování chyb', ne průmysl založený na bezpečnostním cirkusu.

-- Ingo Molnár

Problémy se snímky v ext4

napsal Jonathan Corbet, 8. června 2011

Patch pro souborový systém next3, který do souborového systému ext3 přidal snímky [snapshot], se objevil o něco málo víc než před rokem; v Jaderných novinách z dané doby se dočtete, že je potřeba tento patch posunout více k ext4, aby ho vůbec bylo možné začlenit. K této změně došlo a nedávné patche pro snímky v ext4 vypadají jako něco, co se blíží ke stavu, ve kterém by to šlo začlenit do hlavní řady. To vedlo k novým stížnostem, které by tento proces mohly poněkud zpomalit.

Jedna stížnost přišla od Josefa Basika:

Pravděpodobně jsem s tím měl přijít dřív, ale proč věnovat tolik snahy, aby se do ext4 natlačila takto invazivní vlastnost, když btrfs tohle všechno již umí? Proč místo snahy přijít se spoustou hacků obcházející myriádu podivných kombinací vlastností v ext4 raději nevěnovat pozornost tomu, aby se btrfs stabilizovalo a bylo připraveno k nasazení?

Ve své odpovědi Amir Goldstein řekl, že jeho zaměstnavatel (CTERA Networks) chce tuto vlastnost v ext4. V produktech se to již dodává a btrfs stále není považován za dostatečně stabilní, aby se v daném prostředí použil.

Další obavy pocházejí ze začlenění takto velké vlastnosti do souborového systému, který má být stabilní a připravený pro produkční nasazení. Nikdo v tuto chvíli nechce zavléct do ext4 závažné chyby. Krom toho snímky aktuálně nefungují se všemi variantami formátu ext4 na disku. Mnoho kombinací vlastností ext4 v současnosti nefunguje dobře, což vede Erica Sandeena k obavě z toho, kam tento souborový systém míří:

Jestli se ext4 vyrovná životnosti ext3, bojím se, že za deset let to bude vypadat spíš jako sbírka zvířátek různých lidí než jako dobře navržený projekt, který drží pohromadě. Jak dlouho ještě můžeme přidávat vlastnosti, které jsou napůl nebo úplně nekompatibilní s jinými vlastnostmi?

Považujte to za volání divočiny, aby se vlastnosti zaváděly pomaleji a celostně...

Správce ext4 Ted Ts'o odpověděl se vzácným (na jadernou komunitu) přiznáním, že technické záležitosti nejsou vždy jediným rozhodujícím faktorem při rozhodování o začlenění vlastností:

Je to něco, z čeho mám občas obavy; a sdílím je s tebou. Zároveň je ale faktem, že jsme jako staří holandští mistři, kteří museli brát v úvahu preference svých patronů (tj. v našem případě lidí, kteří nám dávají výplatu )

V tomto případě si myslí, že mnoho lidí má o snímky zájem. Má obavy, že firmy jako CTERA by mohly přestat ext4 používat, pokud ho nepůjde upravit, aby plnil jejich potřeby. Jeho plán je tedy snímky začlenit, až (1) budou patche dostatečně dobré a (2) bude se zdát, že existuje plán, jak vyřešit zbývající problémy.

O vsyscallech a vDSO

napsal Jonathan Corbet, 8. června 2011

Segmenty „vsyscall“ a „vDSO“ jsou dva mechanismy, které se používají pro zrychlení některých systémových volání v Linuxu. I když je jejich funkce stejná (poskytnout rychlý přístup k funkcionalitě, která nemusí běžet v jaderném (privilegovaném) režimu), jsou mezi nimi výrazné rozdíly. Nedávno se začalo mít za to, že vsyscall zjednodušuje útoky, takže byly sestaveny patche, které ho mají začít pomalu odstraňovat. Diskuze o těchto patchích ukazuje, že neshody o tom, jak komunita řeší bezpečnostní záležitosti, jsou stále stejně silné, jako vždy byly.

Oblast vsyscall je starší z obou mechanismů. Byla přidána jako způsob, jak vykonat specifická systémová volání, která nepotřebují žádná privilegia ke spuštění. Klasickým příkladem je gettimeofday(); všechno, co tato funkce potřebuje, je načíst jaderný náhled na to, kolik právě je. Existují aplikace, které gettimeofday() volají často a to až do té míry, že je musí zajímat každý kousek režie navíc. Aby se to vyřešilo, umožňuje jádro mapovat stránku obsahující aktuální čas v režimu pouze pro čtení do uživatelského prostoru; taková stránka také obsahuje rychlou implementaci gettimeofday(). Použitím virtuálního systémového volání může C knihovna poskytnout rychlé gettimeofday(), které se nikdy nepotřebuje přepnout do jaderného režimu.

Vsyscall má nějaká omezení, mezi jinými je tam místo jenom na pár virtuálních systémových volání. Když se na tato omezení narazilo, jaderní vývojáři vytvořili flexibilnější implementaci vDSO. Rychlý pohled na současný systém ukáže, že se stále používají obě:

$ cat /proc/self/maps
...
7fffcbcb7000-7fffcbcb8000 r-xp 00000000 00:00 0            [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0    [vsyscall]

Klíč k současné diskuzi lze vidět, když stejný příkaz spustíme znovu a porovnáme si výstupy:

$ cat /proc/self/maps
...
7fff379ff000-7fff37a00000 r-xp 00000000 00:00 0            [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0    [vsyscall]

Všimněte si, že oblast vDSO se přesunula, zatímco stránka vsyscall zůstává na svém místě. Pozice stránky vsyscall je pevná, je to součástí jaderného ABI, ale oblast vDSO – stejně jako většina oblastí v rozvržení paměti pro uživatelský prostor – má při každém namapování náhodnou polohu.

Znáhodňování rozvržení adresového prostoru je určitou obranou vůči bezpečnostním děrám. Útočník, který je schopen přepsat zásobník, může často zajistit, aby se funkce v cílovém procesu „vrátila“ na libovolnou adresu. S ohledem na to, co je na dané adrese za instrukci, může tento návrat způsobit téměř cokoliv. Zjevným příkladem je návrat do funkce system() v C knihovně; lze ji použít ke spuštění libovolného příkazu. Jestliže ale pozice C knihovny není známa, je pro exploit těžké až nemožné skočit na užitečné místo.

Ve stránce vsyscall není funkce system(), ale je tam několik strojových instrukcí, které volají systémová volání. S trochou hraní by tyto instrukce mohlo být možné použít při přepsání zásobníku tak, aby se zavolalo libovolné systémové volání s parametry, které nastavil útočník – což není žádoucí výsledek. Bylo by tedy hezké se stránky vsyscall zbavit – nebo ji alespoň umisťovat náhodně, aby se tomuto typu útoku zabránilo. Aplikace bohužel závisí na existenci a přesné pozici této stránky, takže nelze nic dělat.

Až na to, že Andrew Lutomirski přišel na něco, co by se dalo dělat: odstranit všechny užitečné instrukce ze stránky vsyscall. Jedna byla spojena se sysctl nastavením vsyscall64, ta byla užitečná jenom pro user-mode Linux (a nefungovala správně ani tam); jednoduše byla odstraněna. Další nebyly instrukce pro systémové volání jako takové: například pokud se v pravý okamžik skočilo do systémového času (a tedy když se vykonal jako kód), vypadal jako instrukce pro systémové volání. Aby se tento problém vyřešil, byly proměnné přesunuty do samostatné stránky, kde je zakázáno vykonávání kódu.

Zbytek kódu ve stránce vsyscall byl jednoduše odstraněn a nahrazen zvláštní zachycovací [trap] instrukcí. Když se aplikace pokusí zavolat funkci ve stránce vsyscall, jádro to zachytí a požadované virtuální systémové volání emuluje v jaderném režimu. Výsledkem je, že jaderné systémové volání emuluje virtuální systémové volání, které bylo vytvořeno, aby nebylo nutné volat jaderné systémové volání. Výsledkem je „vsyscall“, který trvá o zlomek mikrosekundy déle, ale – což je kritické – neporušuje existující ABI. V každém případě bude zpomalení možné pozorovat jenom v případě, že se aplikace bude pokoušet použít stránku vsyscall místo vDSO.

Současné aplikace by to většinou dělat neměly až na malý problém: glibc stále používá time() z vsyscall. V repozitáři glibc to bylo opraveno, ale tato oprava se k uživatelům nějakou dobu nemusí dostat; do té doby budou volání time() o něco pomalejší než dříve. Neměl by to být problém, ale protože jeden nikdy neví, dal Andy dohromady konfigurační volbu, která zachovává staré způsoby. Každý, kdo má obavy z režie emulované stránky vsyscall, může nastavit CONFIG_UNSAFE_VSYSCALLS a získá původní chování.

Nikdo neměl námitky vůči sadě patchů jako celku, ale Linusovi se vůbec nelíbilo to, jak byla pojmenována ta konfigurační volba; požadoval, aby byla pojmenována CONFIG_LEGACY_VSYSCALLS. A nebo ještě lépe aby změna byla provedena bezpodmínečně. To vedle k poměrně předvídatelné reakci od vývojáře PaX o tom, jak jaderná komunita ráda skrývá bezpečnostní problémy. Na to Linus řekl:

Nazvat staré vdso „NEBEZPEČNÉ“ v konfigurační volbě je prostě stupidní. Je to zpolitizované jméno bez dobrého důvodu kromě tvé politické agendy. A když to řeknu nahlas, začneš chrlit stejné staré nesmysly o bezpečnosti.

Postačí říci, že konverzace od té chvíle poměrně upadla; kdo má zájem, může vlákno sledovat následováním odkazů ve zprávách citovaných výše.

Z diskuze vzešel jeden užitečný poznatek a sice, že statická stránka vsyscall není ve skutečnosti bezpečnostní slabinou; je to jednoduše zdroj, který může útočníkovi zjednodušit zneužití slabiny někde jinde. Jestli tento aspekt činí danou stránku „nebezpečnou“ nebo jenom „zastaralou“ [legacy] budiž cvičením pro čtenáře. Tak jako tak je její odstranění považována za dobrý nápad i když by to mohlo vést k tomu, že v jádře zůstanou neopraveny skutečné bezpečnostní chyby; hádka je o pojmenování.

V době psaní tohoto článku nebyly konečné patche zaslány, ale podoba, kterou na sebe vezmou, bude poměrně jasná. Statická stránka vsyscall nebude existovat ve své současné podobě a aplikace, které ji stále používají, budou fungovat dál o něco pomaleji. Konfigurační volba určující toto chování může existovat, ale nemusí, ale každá distribuce, která bude obsahovat jádro s touto změnou (pravděpodobně 3.1 či novější), bude také mít C knihovnu, která se již nepokouší používat stránku vsyscall. A se štěstím bude zneužití slabin o něco těžší.

Diskuse k tomuto článku

[8an]

Na to Linux řekl

Linux si už konečně uvědomil sebe sama, nebo je to jenom překlep? :o)

[Luboš Doležel (Doli)]

Opraveno

[Aleš Kapica]

Ve své odpovědi Amir Goldstein řekl, že jeho zaměstnavatel (CTERA Networks) chce tuto vlastnost v ext4. V produktech se to již dodává a btrfs stále není považován za dostatečně stabilní, aby se v daném prostředí použil.

Jenom mě se to zdá jako čiré "manažerské rozhodnutí"? Aneb jak něco rozdrbat jen kvůli osla, který nejspíš absolutně nechápe co je to open source a má obavu z toho že by Oracle mohl btrfs uzavřít.

[trekker.dk]

Jakou má souvislost uzavření btrfs a stabilita?

[Aleš Kapica]

Třeba tu, že zavedením téhle funkcionality budou definitivně uťaty řeči o stabilitě ext4.

[trekker.dk]

No v tom teda žádnou souvislost s uzavřením btrfs nevidím...

[Aleš Kapica]

Chápu. Na tohle už je totiž třeba vyšší logika.

[trekker.dk]

Nebo tvoje "logika"...

[Aleš Kapica]

No, dle níže uvedených reakcí nejen moje.

[trekker.dk]

Nenamáčej do toho ostatní a zkus přímo odpovědět na otázku, jak souvisí stabilita btrfs s uzavřením btrfs.

[Aleš Kapica]

Ach jo. Že já se nechám vždycky vyprovokovat abych tebou ztrácel čas. Ale budiž.

Vedení firmy CTERA Networks dodává svá řešení na systému, který primárně buduje nad ext4, který považuje za stabilní. Přičemž jak vyplývá nejenom ze zkušeností mých ale i následujícího výše uvedeného textu zas o moc stabilní systém nejde. Ale budiž.

Někde se dočetli o btrfs a výhodách snapshotů a rádi by tuto funkcionalitu rovněž využívali. Jenže se také dočetli, že za vývojem btrfs stojí firma Oracle. Táž firma, která spolkla SUN a tím potažmo i získala patentová práva k ZFS.

Kromě toho se v souvislosti s btrfs neustále omílá že nejde o systém stabilní. Jeho vývojáři si tím jistí záda a fanoušci ext systémů to rádi používají jako argument proč upřednostnit ext4 před btrfs. Ale budiž.

A teď k meritu věci - přidání nové funkcionality do ext4 pro kterou navíc nebyl navržen, znamená nový vývoj a o výsledku lze hovořit jako o stabilním pouze s notnou dávkou fantazie. Ale budiž. Důvodem proč raději rozházet něco již funkčního a odladěného (jak doufám), než přijmout "konkurenční" FS může být právě obava vedení firmy CTERA Networks z toho, že by Oracle provedl s tímto FS nějakou levárnu (kupř. kód nějakým způsobem uzavřel etc.). Tento důvod mi přijde mnohem logičtější než odvolávání se na stabilitu či nestabilitu.

Pokud by totiž CTERA Networks měla zájem na stabilním FS, tak by naopak podnikla vše pro to, aby bylo btrfs co nejdříve uvedeno do stavu aby mohlo být prohlášeno za stable. Z hlediska mojí logiky by to bylo mnohem efektivnější a rychlejší řešení, než se pokoušet roubovat něco na ext4.

No a pak je tu ještě jeden pravděpodobný důvod - obava fy. CTERA Networks z toho, jakým způsobem by realizovala ev. přesun stávajích systémů jimi dodaných na nový FS. Proto chce raději něco k tomu stávajícímu jen tak přilepit. Osobně bych se takové výměny hlavního FS zase tak nebál, vzhledem k tomu, že to již několikrát prováděl, dokonce i za běhu systému.

Tak už je to jasnější?

[phax7]

"CTERA Networks dodává svá řešení na systému, který primárně buduje nad ext4, který považuje za stabilní."

vs

"Přičemž jak vyplývá nejenom ze zkušeností mých ale i následujícího výše uvedeného textu zas o moc stabilní systém nejde. "

Věřím CTERA Networks protože mají hustý název:)

[Trained.Monkey]

Jestli se nepletu tak snapshoty pouzivali uz s Ext3. Mozna se jim proste nechce zahodit zkusenosti ktere maji.

Navic si dovolim pochybovat jestli Btrfs vubec nekdy bude stejne pouzitelny jako EXT4. Nektere navrhy vypadaji dobre na papire, v praxy uz je to ale horsi.

[Aleš Kapica]

Kdybys byl s btrfs nějakou praxi měl, tak bys takovou blbost nenapsal.

[misch]

Přičemž jak vyplývá nejenom ze zkušeností mých ale i následujícího výše uvedeného textu zas o moc stabilní systém nejde.
Ze kterého "následujícího výše uvedeného" textu si mám odvodit že ext4 není příliš stabilní?

[Aleš Kapica]

Jsi blbý, nebo to jen tak hraješ? Když to jsou schopni najít jiní, proč ne ty?

[trekker.dk]

Tak tomu říkám kultivovaná diskuze...

[trekker.dk]

To jsi mohl říct rovnou, že nijak. To, co jsi tady napsal, není nic jiného než spousta nepodložených spekulací.

[mimi.vx]

nebude to tim ze vetsina produkcnich systemu jede na rodine fs ext...."?

ze je pro tohle dost dokumentace, nastroju i zkusenych lidi okolo narozdil od brtfs u ktereho je stale poznamka ze se muze diskovy format zmenit?

[Aleš Kapica]

nebude to tim ze vetsina produkcnich systemu jede na rodine fs ext...."?

ze je pro tohle dost dokumentace, nastroju i zkusenych lidi okolo narozdil od brtfs u ktereho je stale poznamka ze se muze diskovy format zmenit?

No možné to je. Ovšem byly to systémy ext[3|4], které mě už několikrát vypekly. Nic však není černobílé. Na btrfs mám sice přehozená data už druhým rokem, ale pro uložení disků virtuálních strojů se moc nehodí, takže se držím osvědčeného reiserfs. Zkusil jsem i ext4. Zpočátku se to zdálo v pohodě, než přišla ta nemilá příhoda s poškozeným diskem.

[Aleš Kapica]

Jo a teď už to neřeším, protože ty virtuální stroje budou stejně na ocfs2.

[David Jaša]

..., ale pro uložení disků virtuálních strojů se moc nehodí, ...

Proč nemít disky rovnou na LV a nezbavit se tak jedné přebytečné vrstvy?

[Aleš Kapica]

Možností LV se nijak nezříkám, ale prozatím mi přišlo jednodušší využít vlastností DRBD. Tady o tom píšu více.

Pokud bych měl virtální stroje umístěné na samostatné LV oddíly, tak by pro mě (možná) bylo komplikovanější zajistit jejich replikaci. I když.. kdo ví.

Momentálně pro účely snapshotování mám vlastní skript, který využívá možností xNBD a live migrace. Libvirt je sice pěkný nástroj, ale snaphoty zrovna moc dobře pořešené nemá.

LV by se sice dalo také docela elegantně využít, ale mám obavu, že bych v tom měl záhy pěkný zmatek. Takhle mám pouze dva LV oddíly, které je třeba monitorovat - systém a data.

[JoHnY2]

To je rozhodne velka vyhoda, ale snapshoty v ext4 stejne nebudou nabizet moznosti btrfs a podle me je to tak velkej zasah, ze minimalne pri pouziti snapshotu muzem pocitat rekneme s rokem neduvery. S ohledem prave na tohle dava mozna vetsi smysl soustredeni se na btrfs.

Stejne jako Ales v tom vidim rozhodnuti shora, i kdyz je potreba priznat, ze vedeni dany firmy tak rozhodlo treba jen kvuli tomu, ze je jejich zakaznici poslali s btrfs do haje a pritom kralovsky zaplatej za podporu snapshotu bez LVM. To uz samozrejme hodne strilim od boku.

[Petr Tomášek]

Pravděpodobně jsem s tím měl přijít dřív, ale proč věnovat tolik snahy, aby se do ext4 natlačila takto invazivní vlastnost, když btrfs tohle všechno již umí? Proč místo snahy přijít se spoustou hacků obcházející myriádu podivných kombinací vlastností v ext4 raději nevěnovat pozornost tomu, aby se btrfs stabilizovalo a bylo připraveno k nasazení?

Jo, to mě připomíná typický komunistický myšlení...

[TM]

Nestálo by za to s tím konečně něco dělat? Takhle se vám to bude jen zhoršovat...

[Petr Tomášek]

Dělat něco se svobomylností? Blbej vtip!

[TM]

Netušil jsem, že se tomu dnes tak říká...

[Petr Tomášek]

Jistě, myslím si, že když někdo napíše užitečnou vlastnost a kód není prasácký a je dostatečně stabilní, tak nevidím důvod, proč by to nemohlo být zařazeno do jádra...

[Petr Ježek]

Problém je, když si to svobodně myslíte jenon vy. Kdepak je ta odpovědnost? Lidé kolem vývoje kernelu si naštěstí nepletou svobodu s ignorancí reality...

[Petr Tomášek]

Ale já bych neměl nic proti tomu, kdyby někdo odmítal začlenění těchto patchů do jádra proto, že jsou nedodělané / prasácké / špatně spravovatelné / et cetera. Takovýto přístup chápu, dokonce si o něm myslím, že je rozumný.

Jenže argumentace zní "protože už existuje jiný FS, který tuto vlastnost implementuje". A to mi přijde ujeté. Něco ve stylu "když to mám já, už to nesmíš mít ty" a podobně...

[Aleš Kapica]

Ale takhle přeci nikdo neargumentoval? S tím aby použili raději btrfs přišel sám vývojář roho rozšíření, jenomže jeho chlebodárce mu jasně řekl: "Ne, tohle nechcem, btrfs není stabilní a krom toho používáme filesystémy ext tak to do toho dodělej." Takže to do té ext4 tedy nějak zabastlil a teď se to pokouší dostat do hlavní vývojové větve jádra, aby se kvůli tomu nemusel patchovat vanilla kernel.

Proti jeho práci tady nikdo nic nenamítá. Konec konců každá dobrá věc si své uživatele najde sama. Ovšem nelze zavírat oči před tím, že implementací takové věci by se rozvrtaly věci, které jsou již z hlediska dalšího vývoje uzavřené a tím pádem i považovány za stabilní. A vývoj nějaké ext5 pokud je mi známo, do níž by takové nové funkcionality bylo možné začlenit nikdo zatím nechystá. Ostatně taky proč.

Z hlediska souborových systémů už je nabídka docela široká a pokrývá široké spektrum možností. Možná je na místě připomenout si, proč vlastně vzniknul ext4 a čím se liší od ext3. A také co to bylo za porod, než se dostal do jakž takž použitelného stádia.

Přitom v té době již takzvaně nestabilní btrfs už fungovalo docela stabilně.

[trekker.dk]

Ale takhle přeci nikdo neargumentoval? S tím aby použili raději btrfs přišel sám vývojář roho rozšíření, jenomže jeho chlebodárce mu jasně řekl: "Ne, tohle nechcem, btrfs není stabilní a krom toho používáme filesystémy ext tak to do toho dodělej."

Citace?

Takže to do té ext4 tedy nějak zabastlil a teď se to pokouší dostat do hlavní vývojové větve jádra, aby se kvůli tomu nemusel patchovat vanilla kernel.

Tak tohle není moc přesný popis minimálně proto, že ten vývojář nejprve zaslal patche, které to samé dodělávaly do ext3. Odmítnuty byly proto, že ext3 už se nemá měnit a že veškeré novoty v extX patří do ext4

Přitom v té době již takzvaně nestabilní btrfs už fungovalo docela stabilně.

Pokud mu třeba nedošlo místo na disku...

[Aleš Kapica]

Ad poslední odstavec. Vlastní zkušenost? Nebo agentura JPP?

Zbytek tvé reakce nemá smysl komentovat.

[trekker.dk]

Ad poslední odstavec. Vlastní zkušenost? Nebo agentura JPP?

Co třeba pravidelné čtení LWN.net?

Zbytek tvé reakce nemá smysl komentovat.

... ano, když nemáš protiargumenty ani nejsi schopen citovat, opravdu nemá smysl komentovat.

[Aleš Kapica]

Fajn. Takže JPP. Kdybys měl nějakou špatnou vlastní zkušenost s btrfs ať již ty, nebo někdo koho osobně znáš, pak by pro mne mělo smysl se nad tím pozastavit. Nepopírám, že btrfs má své bugy, ale ve srovnání s ext4 jde o souborový systém z mého pohledu spolehlivější.

[trekker.dk]

Fajn. Takže JPP.

Zkusil jsi do Googlu zadat to, co psal Jenda o příspěvek níž? Vypadlo by ti třeba tohle: https://bugzilla.redhat.com/show_bug.cgi?id=495683 Nebo ani bugzilla Red Hatu není dostatečně důvěryhodný zdroj? Stejně jako není důvěryhodný "jedna paní" autor btrfs?

[Jendа]

Co třeba zadat do oblíbeného webového vyhledávače btrfs out of space crash?

[Heron]

Mě celkem překvapuje, jak tento problém najednou vyvstal. Tím chcí říct, to opravdu tolik systémů a jejich uživatelů nechají dojít své FS až na vyčerpání posledního bloku?

[pavlix]

Předpokládám, že ano.

[Ladicek]

Tuhle jsi tu dštil síru na Sqlite, protože se neví, co se stane, když bude mít datový soubor víc než nějaké čtyři tera (nebo kolik bylo to číslo). U souborového systému ti neošetření hraničních podmínek nevadí?

[pavlix]

Hmm, ty máš koukám přehled :).

[Bilbo]

Občas se to stane. Stačí třeba nějaký nepovšimnutý log co roste nade všechny meze, nebo člověk rozbalí nějaký větší tarball do /tmp a zapomene že zatímco v home je půl terabajtu místa, tak /tmp je na poměrně malém SSD, kde už moc místa nezbývá. Na notebooku, kde je malý disk se mi to už asi jednou nebo dvakrát stalo.

Osobně občas nechávám filesystém zaplnit do posledního bloku naschvál (Krok 1 - smazat "citlivé" soubory. Krok 2. - přemazat volné místo na disku/kartě/flashce a citlivé soubory už nejsou ...)

[Jendа]

Na notebooku, kde je malý disk se mi to už asi jednou nebo dvakrát stalo.

Potvrzuji, já mám na desktopu zase 50 GB / a 200 GB datovou oblast (většina ~) a povedlo se mi to taky. Naštěstí to nemělo fatální následky pro systém, protože mám (ext4) rezervováno pár bloků pro roota.

[Heron]

Já si myslím, že ta hlavní příčina je jinde. ext3 + snapshoty != ext3, stejně tak ext4 + snapshoty != ext4.

A o to jde. Ty systémy byly nějak navženy, ten návrh byl v jisté fázi uzavřen a implementován. To co vzniklo, nese nějaké jméno a implementace jsou (snaží se), být s tím návhem maximálně kompatibilní.

Není zkrátka možné teď do ext4 přidávat další vlastnosti, které by z toho dělaly zcela jiný produkt, navíc nekompatibilní. Takže, pokud si to pro svoji potřebu označí jako ext4cow asi nelze nic namítat, ale už to není ext4.

Další věcí je, jestli takový nový FS (ext4cow) dávat do jádra. Jak víme, tak nové FS se nepříjímají zrovna nejsnadněji (a má to své dobré důvody) a zde jistě platí argument, proč dávat do jádra FS v devel stavu, který přináší vlastnosti, které už jeden (a ještě nástupce ext4) FS v devel stavu má. Vnikl by tak fork ext4 na dva projekty, které by implemetnovali (mimo jiné) tutéž vlastnost.

[trekker.dk]

Jak víme, tak nové FS se nepříjímají zrovna nejsnadněji (a má to své dobré důvody)

Odkdy? Slušně navržené FS, které nedělají bordel jinde v systému a neduplikují to, co už v jádře je (např. VFS), se AFAIK dostávají vcelku snadno.

[pavlix]

Vždyť ti nikdo nebrání, abys to do své větve jádra zařadil. Možná máš nějakou jinou (více autoritářskou či totalitní) představu o svobodě než třeba já.

[kralyk z abclinuxu]

"Svobomylnost"? Tak tuhle diagnózu jsem opravdu ještě neslyšel, nezávidim

[pavlix]

Jej a já to tak lehce očima doplnil, že jsem si chyby ani nevšiml. Nezbývá než se panu anti-IPv6 trošičku zasmát.

[Conscript89]

Predpokladam ze vsyscall je vec x86_64 jadra, protoze ja ho na me i686 Fedore 15 nevidim.

[i6]

Na (býválém) kubuntu 11.04 32bit taky mám jen vdso

[tom]

Predpokladam ze jde o Josefa Bacika, ne Basika.

[trekker.dk]

Jo, je to špatně i v originálu, v tom odkazovaném mailu je napsáno Bacik.

[dopisovatel]

Dobrý článek. +1

[nyan]

Ve své odpovědi Amir Goldstein řekl, že jeho zaměstnavatel (CTERA Networks) chce tuto vlastnost v ext4. V produktech se to již dodává a btrfs stále není považován za dostatečně stabilní, aby se v daném prostředí použil.

Takze ext4 s temi made-in-garage patchi oni povazuji za "dostatecne stabilni" ? Hezky sem se zasmal.

[dopisovatel]

Typický příspěvek anonymního začátečníka v Linuxu.

[stativ]

No vidíš, já nejsem ani anonymní, ani začátečník a mám na to stejný názor.

[hanzz]

Proc myslis ze nejsou stabilni? Nejaky dukaz? :)

[stativ]

Už ve článku je napsáno: „snímky aktuálně nefungují se všemi variantami formátu ext4 na disku.“ Když k tomu připočteš, že je to zbastleno bez nějakého rozsáhlejšího review a nalepeno do systému, který k tomu vůbec nebyl navržen…

I kdyby to nakrásně fungovalo, bude v tom nejspíš takový bordel, jako je ve sledovacích bodech.

[Aleš Kapica]

To nemá smysl podávat nějaké důkazy lidem, které zajímá z celé diskuze jenom reakce na jejich vlastní příspěvek. Kdyby neměl za málo a pořádně si přečetl ten článek, nebo alespoň ostatní příspěvky v diskuzi, tak by se takhle neptal.

[trekker.dk]

Když k tomu připočteš, že je to zbastleno bez nějakého rozsáhlejšího review

Cože? Několik iterací v LKML, zpracování připomínek, které tam byly vzneseny, to není rozsáhlejší review?

nalepeno do systému, který k tomu vůbec nebyl navržen…

Všechno nové je nalepeno do systému, který k tomu vůbec nebyl navržen. A ejhle, přesto Linux funguje.

[Aleš Kapica]

Když k tomu připočteš, že je to zbastleno bez nějakého rozsáhlejšího review

Cože? Několik iterací v LKML, zpracování připomínek, které tam byly vzneseny, to není rozsáhlejší review?

nalepeno do systému, který k tomu vůbec nebyl navržen…

Všechno nové je nalepeno do systému, který k tomu vůbec nebyl navržen. A ejhle, přesto Linux funguje.

Píšeš to, jako by to snad byla tvoje zásluha.

[stativ]

Cože? Několik iterací v LKML, zpracování připomínek, které tam byly vzneseny, to není rozsáhlejší review?

Co jsem tak hledal, viděl jsem dvě iterace, což není zrovna hodně na něco, co zasahuje snad do všech částí EXT4. A už vůbec se to nedá srovnávat s otestovaností snapshotů u btrfs.

Všechno nové je nalepeno do systému, který k tomu vůbec nebyl navržen. A ejhle, přesto Linux funguje.

Za svým názorem si stojím. Navíc u Linuxu musíš počítat s tím, že tam na výběr jiný systém, který je stejně funkční ale pro implementaci nějaké funkce je navržen lépe ve většině případů neexistuje.

[Lukas]

Cože? Několik iterací v LKML, zpracování připomínek, které tam byly vzneseny, to není rozsáhlejší review?

Ehm, tak co si pamatuju tak ten kod zatim nemel temer vubec zadne review :). Ja videl jen par nekompletnich patchu a to je vse.

Dve iterace to ma proto, ze Amir se rozhodl ze nejdrive posle "nekompletni" patche, ktere nijak nemeni stavajici cesty v ext4, coz byl pekne blby napad.

Ale i "dve iterace" nemeni nic na tom ze je to bastl, ktery jenom supluje to co uz umi dm lepe a s vice funkcekma. Od implementace snapshotu na urovni souboroveho systemu bych cekal vice, *mnohem* vice. V clanku chybi kopa informaci ktere se v tom vlakne probiraly.

[x]

Heh, jelikoz mam tu cest s necim podobnym jen od jiny firmy, tak bych ani nerek. Prodavaj to za dlouhy prachy a jejich modlej kernel (jinak je to zalozeny na CentOSu, kterej pro jistotu nainstalujoou i s Xkama a dalsim bordelem ....) vykazuje tu zajimavou vlastnost, ze load se bezne drzi kolem 15-16 (na 4jadre) a diskovej vykon je naprosto tragickej (2-5MB/s ...).

[pavlix]

Naopak ten příspěvek považuju za přirozenou a velmi rozumnou reakci. Nějaké hloupé ad hominem tu snad už nikoho moc nerozhodí.

[Petr Ježek]

1. Skandinávcům bude muset Al leccos ohledně hub vysvětlovat...
2. Amir si svobodně zvolil dobře placenou nesvobodu pod nekompetentním vedením, dobře mu tak.
3. FS ext4 je právě tak stabilní, jak je stabilní HW, na němž se nachází.
4. Btrfs je zralé na odstranění regresí a povýšení výkonu, aby mělo více smyslu tento FS používat i produkčně.

[Aleš Kapica]

K tomu bodu tři bych jen poznamenal co mne nemile překvapilo.

Na disku se začaly objevovat chyby. OK, stane se. Byly však na něm data. Nikoliv fixní, ale živá - tím rozuměj že se na ten disk postupně lila data nová. Soubory jsem postupně kopíroval pryč. S čím jsem se u jiných FS nesetkal byla skutečnost, že po odstranění souboru, který se původně nalézal v oblasti s vadnými bloky, se pokoušel systém data do těchto vadných bloků znovu zapisovat, místo aby si je interně označil za vadné a přestal je používat. Než jsem na to přišel tak došlo k poškození dalších souborů, které pak nebylo možné překopírovat jinak, než přes dd_rescue.

Osobně mám za to, že dobrý FS by měl být navržen tak, aby pravděpodobnost poškození dat snížil na minimum i v případě hardwarového problému.

[trekker.dk]

Osobně mám za to, že dobrý systém má být navržen tak, že pokud jsou na disku vadné bloky, je možné takový disk bez ztráty dat vyndat a dát tam jiný.

Jo a jestli tohle je tvůj jediný argument proti stabilitě stávajícího ext4, tak být tebou raději mlčím.

[Aleš Kapica]

Osobně mám za to, že dobrý systém má být navržen tak, že pokud jsou na disku vadné bloky, je možné takový disk bez ztráty dat vyndat a dát tam jiný.

Asi ti splynul systém ve smyslu OS se souborovým systémem. Mám-li totiž dobře navržený systém ve smyslu OS, tak nemám nikdy souborový sytém přímo nad fyzickým zařízením, ale vždy nad nějakým RAID zařízením.

Ovšem je-li souborový systém umístěn přímo nad fyzyckým zařízením, tak má být navržen tak, aby v případě, že se během provozu objeví vadné bloky do nich nezkoušel znovu zapisovat. Chápu že žádný FS nefunguje na bázi delfské věštírny, aby tušil, který blok se zrovna posere, ale uložit záznam o tom že blok xxxx je problémový přeci zase tak problémové není.

Pokud vím, tak kupř. reiserfs udržuje při zápisu informace o datech v paralelní struktuře, takže když se něco posere a systém klekne tak je zřejmě je schopen tohle nějak ošetřit.

Btrfs zase počítá kontrolní součty a interně data komprimuje - proto také není moc vhodný jako FS tam, kde se data často mění, protože je pak při IO operacích pomalejší. Ale opět. Z reálného použití mám dojem že byl navržen tak, aby počítal s možností výskytu vad na HDD.

Jo a jestli tohle je tvůj jediný argument proti stabilitě stávajícího ext4, tak být tebou raději mlčím.

Opět vidíš trávu růst. Mě nezajímá nějaké prohlášení o stabilitě, ale to zda se to stabilně chová. A pokud jde o souborové systémy, tak každý má svá pro i proti, vybrat si musí každý sám. Ovšem chtít aby jeden FS obsáhnul vše, nutně dopadne stejně jako když pejsek s kočičkou pekli dort.

[trekker.dk]

Asi ti splynul systém ve smyslu OS se souborovým systémem

Nikoliv. Slovo systém jsem zde použil jako výraz pro soustavu vzájemně propojených komponent. V tomto případě od hardwaru po OS.

Ovšem je-li souborový systém umístěn přímo nad fyzyckým zařízením, tak má být navržen tak, aby v případě, že se během provozu objeví vadné bloky do nich nezkoušel znovu zapisovat.

Uznávám, že by to bylo lepší, nicméně pro mě to není nijak zásadní kritérium. Proto, že bych se zápisu nových dat na špatný disk pokusil za každou cenu vyhnout. A navíc systém, kde by nebyl RAID, neprovozuju - ani na desktopu.