Jaderné noviny – 12. 5. 2010

31. 5. 2010 | Jirka Bourek | Jaderné noviny | 3529×

Aktuální verze jádra: 2.6.34-rc7. Citáty týdne: Glauber Costa, Matthew Garrett. Adaptivní cyklické futexy. Uprobes se vrací – zase. Detekce vzorců nečinnosti. Souborový systém Next3. Přechod x86 k LMB. MeeGo a Btrfs.

Obsah

• Aktuální verze jádra: 2.6.34-rc7
• Citáty týdne: Glauber Costa, Matthew Garrett
• Adaptivní cyklické futexy
• Uprobes se vrací – zase
• Detekce vzorců nečinnosti
• Souborový systém Next3
• Přechod x86 k LMB
• MeeGo a Btrfs

Aktuální verze jádra: 2.6.34-rc7

Současné vývojové jádro je stále 2.6.34-rc7 vydané 9. května. Linus říká: Myslím, že je to poslední -rc, co se patchů týče, věci byly poměrně tiché, i když se objevily nějaké náruživé diskuze. Kompletní changelog obsahuje všechny detaily.

Podle nejnovějších informací je v 2.6.34 24 nevyřešených regresí.

Stabilní aktualizace: aktualizace stabilních jader 2.6.32.13 a 2.6.33.4 vyšly 12.  května. Obě jsou velké – řádově 100 patchů každá – a opravují mnoho závažných problémů.

Citáty týdne: Glauber Costa, Matthew Garrett

Vedlejším efektem tohoto patche je odstranění schopnosti KVM hostů cestovat v čase.

-- Glauber Costa

Ale v okamžiku, kdy přidáváš do uspávací funkce každého ovladače kód, abys zjistil, jestli nezbývají nějaké události, které uživatelský prostor ještě nezpracoval, a do každého kousku uživatelského prostoru kód, který zjišťuje, jestli ovladač zpracovává události nebo jenom vykresluje poskakující 3D krávu, pak bych řekl, že jsi právě znovuobjevil blokování uspání.

-- Matthew Garrett

Adaptivní cyklické futexy

napsal Jonathan Corbet, 11. května 2010

Obecné pravidlo je, že dobře napsaný program by měl, když potřebuje použít nějaký zdroj aktuálně zabraný jiným programem, ustoupit a nechat pracovat něco jiného, dokud se zdroj neuvolní. Když ale dojde na nízkoúrovňová synchronizační primitiva, toto pravidlo vždy neplatí. Lepší celkové výkonnosti systému lze často dosáhnout tak, že program aktivně čeká, místo toho aby spal. Pokud je čekání krátké, výkonnostní zisky, které pocházejí z předání zdroje již běžícímu procesu, který je nahraný v cache CPU i s daty, převažují náklady na aktivní čekání.

Nejlépe (jádrem) podporované synchronizační primitivum pro uživatelský prostor je futex. Darren Hart pracuje na sérii patchů, jíž cílem je přinést adaptivní cyklické čekání do futexů, aby se zlepšila výkonnost vícevláknových aplikací. Tyto patche, i když jsou stále označeny jako „nepřipraveny na začlenění“ se postupem času významně vyvinuly.

Základní nápad je jednoduchý: Pokud se proces pokusí zabrat futex, který již někdo jiný vlastní, bude běžet v cyklu, dokud nebude futex držícím procesem uvolněn nebo dokud nebude proces odstraněn plánovačem. Pokud bude vše fungovat dobře, nový proces bude mít možnost zabrat futex rychle a pokračovat v práci nejefektivnějším možným způsobem. V praxi adaptivní cyklické futexy obvykle ve výkonnosti překonají běžné futexy, ale jenom občas jsou na tom lépe než vysoce vyladěné v assembleru napsané adaptivní cyklické mutexy, které používá knihovna pthreads.

Adaptivní cyklus vyžaduje, aby jádro vědělo, které procesy aktuálně futex vlastní; to je trochu problém, protože současné operace s futexy tuto informaci neposkytují. V situacích, kde se má používat adaptivní cyklus, je tedy zapotřebí nová operace zamykání.

Několik vývojářů navrhlo alternativní přístup: Nechat cyklus běžet v uživatelském prostoru místo v jádře. Běh v cyklu v uživatelském prostoru by mohl být rychlejší, ale je také složitější, protože pro uživatelský prostor je těžší vědět, jestli současný držitel futexu běží, nebo ne. Poskytování potřebných informací bude vyžadovat návrh zvláštního (a rychlého) API, což je práce, kterou ještě nikdo neudělal.

Uprobes se vrací – zase

napsal Jonathan Corbet, 11. května 2010

Příběh modulu usond [uprobes] se stává jedním z těch delších v jaderné vývojové komunitě. Nyní je to již několik let, co se vývojáři snaží dostat tento kód – který umožňuje vložení dynamických sledovacích bodů do programů v uživatelském prostoru – do hlavní řady. Na usondy jsme se naposledy dívali v lednu; nyní se blíží začleňovací okno 2.6.35 a usondy se chystají na další kolo.

V tomto okamžiku jsou usondy zcela odděleny od vrstvy utrace, která není součástí této série patchů. Utrace je kontroverzní samo o sobě a ukázalo se, že v začlenění usond příliš nepomáhá. Mezi další provedené změny patří přidání rozhraní pro subsystém sledování a událostí výkonnosti [perf events]. To znamená, že dynamické sondy lze vložit z příkazové řádky a pak je pozorovat pomocí rozhraní ftrace nebo perf.

Na druhou stranu si usondy ponechávají mechanismus „vykonávání jinde“ [execute out of line, XOL] pro vykonání kódu, který byl přepsán sondou. XOL funguje, ale za cenu vložení nové oblasti virtuální paměti do zkoumaného procesu; to znamená větší rušení, než se některým vývojářům líbí. Alternativa – přidání emulátoru těchto instrukcí do jádra – je ale invazivní také, jenom jiným způsobem.

Komentáře u revizí se zatím zaměřovaly jenom na relativně malé detaily. To neznamená, že usondy budou přijaty, až se otevře začleňovací okno, ale zdá se to být pravděpodobnější než v minulosti.

Detekce vzorců nečinnosti

napsal Jonathan Corbet, 11. května 2010

Subsystém cpuidle je pověřen tím, aby CPU přepínal do optimálního režimu spánku, když není co na práci. Jedním z klíčových vstupů pro toto rozhodnutí je příští naplánovaná událost časovače; tato událost stanovuje nejzazší hranici toho, jak dlouho se od procesoru dá očekávat, že bude spát nerušen. Čím déle před příští událostí časovače, tím vhodnější je hlubší spánek.

Události časovače ale nejsou to jediné, co může procesor probudit; přerušení od zařízení to udělají také. Občas se stává, že lze od hardwaru očekávat, že přeruší mnohem dříve, než vyprší nejbližší časovač, ale pro procesor je obtížné to předpovědět. Zdá se nicméně, že existuje jedna výjimka: Hardware občas přerušuje tak pravidelně, že to samo o sobě lze považovat za určitý druh tikání časovače. Takový vzor může vygenerovat hýbání myší; provoz na síti také. V takových situacích governor cpuidle „menu“ může opakovaně volit špatný režim spánku.

Arjan van de Ven spěchá na pomoc s jednoduchým patchem cpuidle, který udržuje pole posledních osmi období spánku. Kdykoliv se má procesor uspat, vypočítá se standardní odchylka těchto období; pokud je malá, pak je průměrná doba spánku považována za lepší ukazatel očekávané doby spánku než příští událost časovače.

Jak je u učících se strojů běžné, kód je relativně jednoduchý. Měl by ale být dostatečně chytrý na to, aby zachytil jednoduché vzory a hardware tak běžel trochu blíže k optimálnímu režimu.

Souborový systém Next3

napsal Jonathan Corbet, 11. května 2010

Souborový systém ext3 je vyzkoušený a poctivý, ale neobsahuje mnoho vlastností, které současní uživatelé považují za zajímavé. Snímky [snapshots] – možnost v libovolném čase rychle zachytit stav souborového systému – jsou na vrcholu mnoha seznamů. V současnosti je možné použít s ext3 snímky generované pomocí LVM, ale ty mají určitá poměrně významná omezení. Souborový systém Next3 nabízí přístup, který by se mohl ukázat jako jednodušší a flexibilnější: Snímky implementuje přímo v ext3.

Next3 byl vyvinut v CTERA Networks, začali ho dodávat na svém síťovém úložišti C200. Kód byl také zaslán na SourceForge a navržen k začlenění do hlavní řady jádra. Next3 přidává jednoduché generování snímků takovým způsobem, který je (z větší části) kompatibilní s existujícím formátem na disku. Tato vlastnost vypadá užitečně, ale její začlenění do hlavní řady bude delší, než její autoři doufali.

Souborový systém Next3 je nový typ souborového systému – není to jenom vylepšení ext3. Ve svém jádře funguje tak, že vytvoří zvláštní, kouzelný soubor, který reprezentuje snímek souborového systému. Takový soubor má stejnou velikost jako celý svazek, ale je řídký, takže zpočátku nezabírá téměř žádné místo. Když se mění blok na disku, souborový systém nejprve kontroluje, jestli tento blok byl již uložen do nejaktuálnějšího snímku. Pokud ne, je dotyčný blok přesunut do souboru se snímkem a jako náhrada je alokován nový blok. Postupem času se tedy bloky na disku stěhují do souboru se snímkem s tím, jak jsou přepisovány novým obsahem.

Přístup ke snímku pouze pro čtení je jednoduchou záležitostí připojení souboru se snímkem ve smyčce [loopback] jako souborový systém ext2. Soubor se snímkem je dostatečně kouzelný na to, aby pokusy přečíst bloky v dírách (které reprezentují bloky, které se od vzniku snímku nezměnily) byly uspokojeny z novějších snímků – které budou obsahovat obsah daného bloku z doby, kdy se konečně změnil – nebo přímo z úložného zařízení. Smazání snímku vyžaduje přesun změněných bloků do předchozího snímku, pokud existuje, protože mazaný snímek obsahuje bloky, které jsou součástí předchozích snímků.

Změny formátu ext3 na disku jsou minimální do té míry, že lze Next3 připojit obyčejným kódem ext3. Pokud ovšem existují snímky, nemůže být ext3 dovoleno souborový systém měnit, jinak by změněné bloky nebyly do snímků uloženy. Pokud tedy na souborovém systému existují snímky, je označen příznakem vlastnosti [feature flag], který vynucuje připojení v režimu pouze pro čtení.

Na straně výkonnosti jsou prý dobré zprávy. Zápisy jsou o něco pomalejší kvůli nutnosti přesunout starý blok do snímku. Nejhorší dopad na výkonnost je podle všeho u operace zkrácení [truncate]; u té může být potřeba uložit velký počet bloků, čímž se může hodně zpomalit. Také je potřeba poznamenat, že přesun změnených bloků do souboru se snímkem časem rozbije hezký spojitý formát na disku, který se ext3 tak snaží udržovat, což má nešťastné dopady na proudové čtení. Soubory, které nesmí být fragmentovány, lze označit zvláštním příznakem, který zajistí, že se změněné bloky do snímku budou kopírovat, ne přesouvat; to zápisy ještě zpomalí, ale soubor na disku zůstane spojitý.

Vývojář Next3 Amir Goldstein požádal o relativně rychlé revize patchů, protože se pokouší dokončit nějaké formátování na disku. Odpověď, kterou dostal od Teda Ts'o, pravděpodobně nebyla to, co očekával:

V sérií ext2/3/4 probíhá nový vývoj v ext4. Vylepšení jako Next3 pravděpodobně nebudou v ext3 nijak uvítána.

Amir odpověděl, že i když je portování patchů na seznamu „někdy se k tomu dostaneme“, daný port není jednoduchá záležitost. Největší problém je zjevně zajistit, aby přesun bloků do souboru se snímkem fungoval správně i s formátem ext4 orientovaným na rozsahy. Krom toho Amir říká, že se ve skutečnosti nepokouší začlenit změny do ext3 – chce začlenit oddělený souborový systém nazvaný Next3, který shodou okolností bude víceméně kompatibilní s ext3.

Přístup „oddělený Next3“ se ale asi také daleko nestane. Jak to řekl Ted, ext2, ext3 a ext4 jsou ve skutečnosti pouze různé implementace stejného základního formátu souborového systému; tento formát nikdy nebyl forkován. Next3 jako souborový systém by byl forkem tohoto formátu. Fakt, že Next3 převzal některá pole v datových strukturách, která se v ext4 používají k něčemu jinému, nepomohl:

„ext“ v ext2 znamená "extended" (rozšířený), tj. „druhý rozšířený souborový systém“ pro Linux. Možná by bývalo lepší, kdybychom použili termín „extensible“ (rozšiřitelný), neboť to je to hlavní, co ext2/3/4 drželo při životě. To je důvod, proč mám námitky k tomu, že Next3 používá některá pole, která se překrývají s ext3. Znamená to, že e2fsprogs, které podporují jeden a pouze jeden formát souborového systému, by nyní musely podporovat dva formáty. A to není něco, co bych chtěl dělat.

Odpověď vypadá poměrně jasně: Patche přidávající snímky by byly vítány, ale ne jako fork souborového systému ext3. Přinejmenším by bylo potřeba změnit formát souborového systému tak, aby se zabránilo konfliktům s ext4, ale skutečné řešení je podle všeho jednoduchá implementace patchů nad ext4, a ne nad ext3. To představuje spoustu práce navíc, které se vývojáři Next3 mohli vyhnout, kdyby o svém záměru dali vědět komunitě předtím, než začali pracovat na kódu.

Přechod x86 k LMB

napsal Jonathan Corbet, 11. května 2010

Pro některé testery byl vývojový cyklus 2.6.34 zpočátku poněkud náročnější kvůli potížím způsobeným patchi NO_BOOTMEM, které se objevily během začleňovacího okna. Problémy daného kódu byly nakonec zlikvidovány, ale v 2.6.35 to opět může být zajímavé – Yinghai Lu je zpět s další sadou patchů, která pokračuje v kompletním přepracování toho, jak funguje alokace paměti při bootu na architektuře x86. Taková práce má vždy potenciál pro způsobování problémů, ale konečný výsledek vypadá jako něco, co má smysl.

Pro uvedení do obrazu: V běžícím jádře je správa paměti řešena alokátorem stránek buddy (na úrovni stránek), slab alokátor běží nad ním. Tyto alokátory jsou složité kusy kódu a nemohou běžet bez z větší části funkčního jádra, takže je není možné použít během počáteční fázích bootu. Místo toho se používá řetěz jednoduchých alokátorů specifický pro architekturu. U x86 věci začínají mechanismem podobným brk(), který přechází do kódu počátečních rezervací [early reservation] „e820“, který následně předává kontrolu alokátoru bootmem. Jakmile bootování dostatečně pokročí, slab alokátor může od kódu bootmem převzít řízení. Změny, které do 2.6.34 zaslal Yinghai, umožňují přeskočit fázi s bootmem, což systému umožní používat kód počátečních rezervací, dokud není možné použít slab.

Během revizí tohoto kódu se někteří revidovatelé ptali, proč x86 nepoužívá alokátor „logický blok paměti“ [logical memory block, LMB] místo vlastního kódu počátečních rezervací. LMB se v současnosti používá v architekturách Microblaze, PowerPC, SuperH a SPARC, takže vypadá jako obecné řešení. Používání obecného kódu má oproti variantám specifickým pro architekturu zjevné výhody; na kód se dívá víc očí a celkové náklady na údržbu jsou omezeny. Přechod k LMB tedy zjevně dává smysl.

LMB je, jak by se dalo očekávat, opravu jednoduchý správce paměti. Nízkoúrovňový kód architektury mu předává bloky paměti ke správě, když je najde, voláním:

long lmb_add(u64 base, u64 size);

Alokátor tuto oblast uloží do pevně daného pole známých bloků paměti, přičemž ji sloučí s ostatními existujícími bloky, pokud je potřeba. Paměť lze následně alokovat:

u64 lmb_alloc(u64 size, u64 align);

Alokované bloky jsou sledovány v druhém poli, které vypadá stejně jako první; alokace je uspokojena procházením dostupných bloků, přičemž se hledá dostatečně velký kus, který nerezervoval nikdo jiný. Jsou zde i další funkce pro rezervaci specifických oblastí paměti, alokaci paměti na specifických NUMA uzlech atd. Ve svém jádře je ale LMB jednoduchý alokátor, který má fungovat dostatečně dobře do doby, než může začít pracovat něco sofistikovanějšího.

Yinghaivova sada patchů významně mění i kód LMB počínaje tím, že ho přesouvá z adresáře lib do mm ke zbytku kódu správy paměti. Přidávají se nějaké funkce, které odpovídají odlišné sémantice podporované kódem časných rezervací, který funguje v dvoukrokovém režimu „najdi blok paměti a pak ho rezervuj“. Také je zde nová funkce, která předává rezervace od LMB alokátoru bootmem pro konfigurace, kde se bootmem používá. Série o 22 částech vrcholí přechodem časných alokací na LMB a odstranění kódu časných rezervací.

O této sérii patchů, která dělá tak významné změny, se překvapivě málo diskutovalo. Zdá se, že většina vývojářů jádra věnuje jenom málo pozornosti tomu, co se děje na úrovni specifické pro architektury. Jednou výjimkou je Ben Herrenschmidt, který hlídá LMB z perspektivy PowerPC. Ben nesouhlasí s mnoha změnami na úrovni LMB, má pocit, že komplikují API a potenciálně mohou zavést problémy. Místo toho se zdá, že Ben by rád opravil kód LMB sám, s tím že Yinghai by pracoval na částech specifických pro x86.

Proto zaslal vlastní sérii patchů a řekl:

Mým cílem je stále nahradit spodní část Yinghaiovy série patchů a ne pracovat nad ní. Následně přidat všechno, co je potřeba kvůli portu x86, a změnit NO_BOOTMEM na něco napůl rozumného bez přidávání tuny zbytečného bordelu do jádra LMB.

Některé změny jednoduše pročišťují kód LMB, například přidávají makro for_each_lmb() pro procházení polem bloků paměti. Pole o pevné velikosti se mění na proměnlivou délku, fyzické adresy reprezentuje phys_addr_t a kód je významně reorganizován. Toho, co Ben plánuje udělat, je hodně, včetně – naštěstí – přidání dokumentace API, ale i bez toho se jedná o významné pročištění kódu LMB.

Stejně jako Yinghaiovy patche i tyto přitáhly jenom malou diskuzi. Změny se možná neobjeví na radaru do doby, než se obě sady patchů sloučí a budou – možná – začleněny do 2.6.35. Při troše štěstí se na radaru neobjeví ani poté a rozdílu si všimne jenom pár lidí.

MeeGo a Btrfs

napsal Jonathan Corbet, 11. května 2010

MeeGo je pravděpodobně černý kůň v závodě mobilních platforem: Je nový, nedokončený a není k dispozici na žádném aktuálně dodávaném produktu. Představuje spojenou snahu dvou významných hráčů na trhu, kteří se obvykle pomalým tempem pokouší nastartovat skutečně na komunitu orientovaný vývojový proces. V současnosti se nicméně důležitá rozhodnutí pro vývoj odehrávají centrálně. Nedávno vyšlo na světlo jedno poměrně významné rozhodnutí: MeeGo bude mít jako výchozí souborový systém Btrfs.

Btrfs je považován za dlouhodobou budoucnost souborových systémů pro Linux, reprezentuje tolik potřebné čisté oddělení od starých návrhů souborových systémů, které jsme používali celá léta. Se skonem reiser4 a nedostupností ZFS by se zdálo, že v tomto ohledu je Btrfs jediný soutěžící. Rozhovory o Btrfs jsou však vždy obaleny výrazy jako „ještě není stabilní“ a jenom pár lidí se odhodlá k tomu sdělit nějaké datum, kdy by tento souborový systém mohl být nasazován do produkčního použití. Jádro 2.6.34 bude stále vydáno s textem, který hlídá záznam u konfigurační volby pro Btrfs:

Btrfs je vysoce experimentální a FORMÁT NA DISKU JEŠTĚ NEBYL DOKONČEN. Zde byste měli zvolit N, pokud nemáte zájem testovat Btrfs s daty, která nejsou kritická.

K vydání MeeGo 1.0 může dojít i během tohoto měsíce; vzhledem k tomu by slova výše mohla znít trochu děsivě. Ve skutečnosti jsou možná trochu děsivější, než je potřeba: Další změny formátu na disku se neočekávají. Varování bude podle všeho trochu zmírněno v 2.6.35.

Proč si tedy pro MeeGo vybrat Btrfs? Arjan van de Ven rozhodnutí popsal takto:

Je budoucností souborových systémů pro Linux. Máme zde případ, kdy starý hlídač (ext3) odchází do důchodu a na stole jsou dva nové souborové systémy (btrfs a ext4). Měli jsme pocit, že kdybychom si vybrali ext4, měli bychom problémy s novým souborovým systémem a za rok bychom museli podstoupit změnu na btrfs.

Pokračoval popisem toho, proč na platformě MeeGo dává Btrfs smysl počínaje vlastnostmi pro celistvost dat. Návrh kopírující při zápisu, který je jádrem Btrfs, má mnoho hezkých atributů, jedním z nich je, že uživatel by nikdy neměl v souborech najít nesmysly, ani v situaci „v nejhorším možném okamžiku vytažená baterie“. To se pochopitelně výrobcům zařízení líbí.

Pro prostředí MeeGo je zajímavá i komprese na disku. Systém nahrávaný do zařízení zabírá méně místa a uživateli zařízení je tak k dispozici více. Jak ale upozorňuje Arjan, výrobcům se to líbí také: Menší systém lze do zařízení nahrát rychleji.

Zdá se, že je mnoho plánů využití vytváření snímků, počínaje odvolatelnou aktualizací balíčků. Se snímky by zařízení mohlo podporovat víceuživatelský režim tak, aby měl každý uživatel zdánlivě celý systém jenom pro sebe. A „reset do továrního nastavení“ je jednoduchá operací, která nevyžaduje samostatný záchranný oddíl na disku. Snímky už nejsou jenom pro uživatele na podnikové úrovni.

Jsou zde další výhody včetně výkonnosti při práci s malými soubory, zabudovanou defragmentací (která je nejužitečnější proto, aby doba bootu zůstala krátká), vlastnosti spojené se správou úložiště a další. Ve zkratce není pochyb o tom, že Btrfs nabízí užitečnou sadu vlastností pro jakoukoliv distribuci; není těžké pochopit, proč ho chce MeeGo používat. To ale zanechává jednu zajímavou otevřenou otázku: Je Btrfs připraven na začlenění do MeeGo, kde bude pravděpodobně instalován na systémy určené pro uživatele, kteří se nechtějí stát testery souborového systému ve fázi vývoje?

Btrfs byl začleněn do jádra 2.6.29; od té doby vypadá aktivita, co se týče patchů, takto:

Souborový systém se tedy plynule mění, významně, ale žádná záplava. Kód má široký rozsah přispěvatelů, většina práce nicméně pochází od vývojářů z Oracle a Red Hatu. Rozhodně jsou lidé, kteří Btrfs běžně používají a Fedora ho nabízí jako experimentální možnost. E-mailová konference stále obsahuje mnoho zpráv o oops a zdá se, že známý problém s NOSPC (kde souborový systém reaguje uboze na to, když dojde místo na úložišti) stále ještě není vyřešen. Patche s významnými vlastnostmi – podporou přímého I/O a RAID4/5 například – stále nejsou začleněny. Ve shrnutí: Btrfs stále nevypadá jako „je hotovo“.

Může být však téměř hotov pro nasazení v omezeném a dobře otestovaném prostředí, kterým pravděpodobně nasazení MeeGo bude. Btrfs se navíc ještě stabilizuje do doby, kdy se začnou zařízení s MeeGo dodávat – přičemž bezpochyby vývojáři MeeGo budou sami pomáhat. Takže i když toto rozhodnutí nyní vypadá ambiciózně, není nutně nerozumné. Platformě černého koně lze využitím nejlepší technologie, která je k dispozici, jenom pomoci.

       

Komentáře

[JVid]

Jaký skon Reiser4 mají na mysli? Edward Šiškin stále vydává patche, ten pro 2.6.34 je na obvyklém místě už pár dní, a navíc se v poslední době rozjelo (trochu i mým přičiněním) další kolo oprav jak jaderného kódu, tak i reiser4progs. Kromě toho loni Edward oznámil, že přes letošní léto napíše pořádnou dokumentaci a pokusí se Reiser4 začlenit. Bez Hanse se mu to snad podaří.

[rini17]

Kym sa za reiser4 nepostavi znama distribucia tak je buducnost dost neista. Okrem toho mna osobne preslo nadsenie ked som po niekolky krat musel nekonecne dlho cakat na fsck.reiser4 --build-fs

[JVid]

No jistě, že vzhledem k minimálnímu počtu uživatelů je budoucnost přinejmenším nahnutá, zvlášť, jestli se nepodaří začlenění, ale mluvit o skonu je přeci jenom poněkud předčasné. Dokud existuje vývojář ochotný (a to velmi :D ) na tom dělat, tak nevidím problém, ale pokud tenhle člověk tráví tři čtvrtiny času tím, že přizpůsobuje kód změnám jaderného API, tak ho to asi moc dlouho bavit nebude. Navíc se pak vývoj moc neposouvá dopředu.

[geebranz]

More likely to work

coloradospringssmallbusinessloans.com

[geebranz]

Amazing application

smallbusinessloansbakersfield.com

[JoHnY2]

Jsem pro btrfs v MeeGo. I kdyz z toho nejspis bude mit Nokia a Intel pekny potize, tak to urcite pomuze btrfs a to je podle tedka dulezitejsi.

[bohyn]

Zrovna vcera sem zkousel, jak Btrfs dopadne, kdyz se mu ustrihne napajeni. Pustil sem 4x kopirovani malych souboru (jpg par kilo az 1MB) a vytahnul disk z USB. Kernel 4x oopsnul, btrfs proces v jadre se zacyklil a tabulka oddilu zkoncila na hadry. Jak dopad fs nevim. Verim ze casem se chybycky vychytaji a bude to dobry fs, ale svoje data bych mu zatim nepucil.

• Kernel 2.6.33.5 Fedora 13 64bit
• Btrfs v0.19

[Petr Ježek]

Zkuste to reportovat. každá přesná zpětná vazba přibližuje okamžik, kdy svá data s láskou "másláku" přenecháte.