Jaderné noviny - 8. 10. 2008

13. 11. 2008 | Jirka Bourek

Články - Jaderné noviny - 8. 10. 2008  

Aktuální verze jádra: 2.6.27-rc9. Citáty týdne: David Miller, Linus Torvalds. Statistiky vývoje 2.6.27. Btrfs do hlavní řady? Přesouvání přerušení do vláken.

Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.

Obsah

• Aktuální verze jádra: 2.6.27-rc9
• Citáty týdne: David Miller, Linus Torvalds
• Statistiky vývoje 2.6.27
• Btrfs do hlavní řady?
• Přesouvání přerušení do vláken

Aktuální verze jádra: 2.6.27-rc9

Současné vývojové jádro 2.6 je 2.6.27-rc9 vydané 6. srpna. Linus říká: Já vím, já vím, říkal jsem, že očekávám, že -rc8 bude poslední a 2.6.27 vydám tento víkend. Lhal jsem. Žalujte mě. Začlenil jsem dnes dvě malé opravy regresí a i když obě vypadaly naprosto v pořádku a byly testovány lidmi, kteří s tou regresí mají něco společného, nemohl jsem se prostě přemoci k jednoduchému vypuštění 'v2.6.27' bez nějakého dalšího testování. Finální vydání 2.6.27 očekávejme v blízké budoucnosti.

Stojí za to poznamenat, že v době psaní tohoto článku 2.6.27 neobsahuje opravu pro chybu poškozující hardware e1000e. Co ale obsahuje, je série patchů, které chybě zabrání ve skutečném poškození hardwaru. Díky tomu je běh jádra bezpečnější, což je důležitý krok správným směrem.

Během minulého týdne nebyly vydány žádné stabilní verze. V době psaní tohoto článku však byly revidovány velké opravy pro jádra 2.6.25 a 2.6.26.

Citáty týdne: David Miller, Linus Torvalds

Nejvíc mě zaujal popis, který dodal Patrick McHardy ke svému novému filtrovacímu frameworku, kde je všechna komplexita v uživatelském prostoru a jádro jenom spouští filtrovací skripty a vyhledává datové struktury, které mu dodaly uživatelské nástroje. V krátkosti si myslím, že tahle věc je skvělá a na rozdíl od některých si vůbec nemyslím, že by to snížilo účast vývojářů.

A upřímně, iptables je rozhodně příliš přístupné přispěvatelům. Podívejte se, kolik smrdících hovínek je v patchoobsluze [patch-o-matic] často nazývané "šmejdoobsluha" [crap-o-matic].

-- David Miller

Pak ale přijde období voleb a připomene vám, že všichni tito Američané, kteří jsou jednotlivě příčetní a normální, najednou mají tendence být společně blázniví a divní. A v tu chvíli si skutečně všimnete, že už nejste ve Finsku.

-- Linus Torvalds si založil blog.

Statistiky vývoje 2.6.27

Opět je zde ten čas vývojového cyklu: jádro 2.6.27 vyjde brzy (pokud již v době, kdy toto budete číst, nebude vydáno). Různé články v Jaderných novinách se zabývaly vlastnostmi, které toto vydání přidává; zde se podíváme na to, kde se ten kód vzal.

Do 2.6.27-rc9 bylo do hlavní řady přidáno celkem 10 604 neslučovacích [non-merge] sad změn; tyto patche přidaly celkem 826 000 řádek kódu a odebraly 608 000, přírůstek je 217 000 řádek. Do 2.6.27 přispělo 1 109 vývojářů reprezentujících přes 150 zaměstnavatelů. 376 z těchto vývojářů v tomto vývojovém cyklu přispělo jedním patchem.

Nejaktivnější vývojáři 2.6.27 byli:

Nejaktivnější vývojáři 2.6.27

Podle sad změn Ingo Molnár 238 2,2 % Bartlomiej Zolnierkiewicz 235 2,2 % Adrian Bunk 221 2,1 % David S. Miller 206 1,9 % Alan Cox 196 1,8 % Yinghai Lu 192 1,8 % Jeremy Fitzhardinge 162 1,5 % Tomas Winkler 128 1,2 % Ben Dooks 120 1,1 % Jean Delvare 113 1,1 % Steven Rostedt 108 1,0 % Harvey Harrison 105 1,0 % Pavel Emelyanov 103 1,0 % Thomas Gleixner 101 1,0 % Jean-Francois Moine 89 0,8 % Lennert Buytenhek 88 0,8 % Hans Verkuil 81 0,8 % Joerg Roedel 81 0,8 % Arnd Bergmann 76 0,7 % David Brownell 75 0,7 %

Podle změněných řádek Paul Mackerras 138374 12,1 % David Woodhouse 44759 3,9 % Jean-Francois Moine 41157 3,6 % Adrian Bunk 35160 3,1 % Artem Bityutskiy 34545 3,0 % Luis R. Rodriguez 31825 2,8 % Sam Ravnborg 27443 2,4 % Karsten Keil 24674 2,2 % Russell King 22861 2,0 % Eilon Greenstein 19470 1,7 % Alan Cox 16957 1,5 % Felipe Balbi 16287 1,4 % Kumar Gala 14490 1,3 % David Brownell 12551 1,1 % Ralf Baechle 11057 1,0 % Lennert Buytenhek 9735 0,9 % David S. Miller 8621 0,8 % Juergen Beisert 8516 0,7 % Steven Rostedt 8455 0,7 % Ben Dooks 8399 0,7 %

Co se sad změn týče, Ingo Molnár obsadil první místo díky vytvoření velkého množství změn spojených s x86, včetně velké reorganizace subarchitektur; Ingovo skóre také zahrnuje přidání ftrace, i když většina tohoto kódu byla napsána jinými. Bartlomiej Zolnierkiewicz pokračuje v přepracovávání staré IDE vrstvy a Andrian Bunk jako vždy energicky pročišťuje kód po celém stromě. Součet Davida Millera zahrnuje kód vícefrontového síťování a spoustu dalších změn. Alan Cox hodně pracoval na TTY a na odstranění velkého jaderného zámku.

Autor tohoto článku se se zklamáním musel spokojit s 23. místem, které ho umístilo na dno tabulky. Je na čase poslat nějaké rychlé opravy bílých znaků. Ale vážněji, stojí za to všimnout si, že ve směsi je tentokrát relativně málo patchů typu "triviální změna".

Pokud se podíváme na změněné řádky, Paul Mackerras skončil na prvním místě díky jedinému patchi, který odstranil zastaralou architekturu ppc. David Woodhouse přepracoval správu firmwaru v celém stromě ovladačů. Jean-François Moine přivedl do stromu ovladač GSPCA pro webkamery, načež vložil ohromnou snahu do jejich pročištění. Artem Bityutskiy přidal flashový souborový systém UBIFS a Luis Rodriguez začlenil bezdrátový ovladač ath9k.

Pokud se podíváme na společnosti za touto prací, dostaneme následující výsledky (mějte na paměti, že jako vždycky jsou tyto výsledky poněkud přibližné):

Nejaktivnější zaměstnavatelé 2.6.27

Podle sad změn (Žádný) 1925 18,2 % Red Hat 1405 13,2 % (Neznámý) 921 8,7 % IBM 791 7,5 % Intel 605 5,7 % Novell 586 5,5 % Movial 234 2,2 % SGI 197 1,9 % (Konzultant) 193 1,8 % Sun 184 1,7 % XenSource 165 1,6 % Parallels 157 1,5 % Oracle 148 1,4 % Marvell 143 1,3 % Fujitsu 138 1,3 % AMD 129 1,2 % Renesas Technology 125 1,2 % linutronix 121 1,1 % Simtec 119 1,1 % (Školství) 108 1,0 %

Podle změněných řádek IBM 207215 18,1 % (Žádný) 129998 11,4 % Red Hat 109970 9,6 % (Neznámý) 108878 9,5 % Nokia 52022 4,5 % Novell 49944 4,4 % (Konzultant) 46529 4,1 % Broadcom 43438 3,8 % Atheros 38212 3,3 % Movial 35439 3,1 % Intel 32887 2,9 % Freescale 25511 2,2 % SGI 23444 2,0 % Marvell 20967 1,8 % Renesas Technology 15723 1,4 % MIPS Technologies 15701 1,4 % Pengutronix 13334 1,2 % Atmel 10786 0,9 % Analog Devices 10725 0,9 % Sun 9176 0,8 %

V této tabulce není mnoho překvapení - konkrétně seznam společností na čelních pozicích se většinou příliš nemění. Jinak řečeno, je jenom málo věcí, na které stojí za to upozornit. Jednou je, že Sun Microsystems se na tomto seznamu objevil poprvé. Lidé si na tuto společnost stěžují, ale technici v Sunu tiše opravovali věci v celém stromě. Broadcom je další společnost, která má v komunitě rozporuplnou reputaci, ale firma s radostí poskytuje podporu pro některé ze svých síťových adaptérů. Silná pozice Nokie v tabulce řazené podle změněných řádek vyplývá hlavně z přispívání do souborového systému UBIFS.

Nejvítanější změna je ale první výskyt Atherosu na tomto seznamu. Atheros je společnost, která se rychle přesunula z pozice absolutní nespolupráce k podpoře veškerého hardwaru v hlavní řadě jádra. Říci, že je to povzbuzující vývoj, by bylo velmi zdrženlivé.

Vývojový cyklus 2.6.27 všehovšudy ukazuje, že proces pokračuje v plném tempu a zdá se, že je vše v pořádku. Vývojáři z různých odvětví průmyslu spolupracují na tom, aby bylo lepší jádro pro všechny. Počet firem, které mají zájem o spoluúčast v tomto procesu, roste, stejně jako roste počet vývojářů, kteří posílají patche. Linuxové jádro je, jak se zdá, v dobré formě.

Btrfs do hlavní řady?

Jeden z jaderných projektů, který v současnosti přitahuje slušné množství pozornosti, je nový souborový systém kopírující při zápisu [copy-on-write]: Btrfs. I když je stále poněkud nehotový - je navržena stabilizace diskového formátu na konci roku - dostal se Btrfs do stavu, kdy chce jeho hlavní vývojář Chris Mason začít mluvit o začlenění do hlavní řady. Někteří jsou pro rychlý postup, zatímco jiní nevěří, že by začlenění vedlo k rychlejšímu vývoji.

Začlenění Btrfs by mělo mnoho výhod, ale Chris se hlavně snaží získat více očí:

Kód je nicméně vyvíjen velmi aktivně a věřím, že nejlepší způsob, jak odteď Btrfs vyvíjet, je dostat ho do hlavní řady jádra (s velkým varovným nápisem ohledně diskového formátu) a přilákat tak rozsáhlé revize jak diskového formátu, tak kódu pod ním.

Vývojáři Btrfs jsou odhodláni souborový systém zprovoznit a dobře fungovat v jaderné komunitě. Myslím si, že se bude konečný výsledek všem více líbit, pokud se mi podaří co nejdříve přitáhnout více očí.

Jaderný kód typicky není začleněn, dokud není připraven, ale lze se dohadovat, že souborové systémy, stejně jako ovladače zařízení, jsou dostatečně oddělené od zbytku jádra, takže brzké začlenění nemůže příliš škodit. Určitý druh precedentu byl také nastaven brzkým "začleněním" ext4, i když to byla evoluce existujícího souborového systému ext3, zatímco Btrfs je zcela nový. Andrew Morton Chrise povzbudil, aby Btrfs dostal do linux-next okamžitě a začlenil ho do 2.6.29. Svůj návrh odůvodnil:

Myslím si, že btrfs má pravděpodobně budoucnost a jeho rychlé začlenění zrychlí vývoj a rozšíří základnu uživatelů. Jestliže z nějakého důvodu selže, no, pak ho můžeme prostě zase smazat.

Z různých důvodů tento přístup, co se obecné politiky týče, není vhodný, ale myslím si, že Linux potřebuje nový lokální souborový systém už nějakou dobu a btrfs může být Ten Správný, takže stojí za trochu speciálního zacházení.

Adrian Bunk není přesvědčen, že brzké začlenění přinese zisky, na které Andrew láká. Ukazuje na časný vývojový plán ext4 s poznámkou, že rozvrh načrtnutý v dané zprávě byl řekněme příliš optimistický. Když to porovnáme s tím, co se stalo ve skutečnosti, poněkud to vyvrací tvé tvrzení o 'zrychlení'.

Jak ale zdůraznil Serge Hallyn, mezi ext4 a Btrfs je rozdíl:

Na druhou stranu - možná si to myslím jen já - ale kolem btrfs je mnohem více aktivity. Já osobně umírám touhou po podpoře snapshotů a nemohu se dočkat, až vyzkouším btrfs na datovém/poznámkovém oddílu (kde mi nevadí ztráta dat). btrfs a nilfs - jů. Ext4? <zív>. To může znamenat rozdíl.

Původní časový rozvrh ukazoval polovinu roku 2007 jako cíl pro stabilní ext4, ale projekt daný termín přetáhl přibližně o rok. Nedávný patch navrhuje přejmenování ext4dev na ext4, protože se stabilizuje natolik, že je čas zahodit příponu 'dev'. Jak popisuje Chris, neočekávané obtíže vedly k tomu, že vývoj ext4 trval déle:

Ext4 se vždy musel potýkat s duchem ext3. Jak z pohledu kompatibility, tak z toho, jakou každý očekával stabilitu. Věřím tomu, že většina z nás podcenila, jak obtížné bude posunout ext4 kupředu.

Mnoho lidí si asi myslí, že Btrfs je na tom jinak, ale ten má před sebou také dlouhou cestu. V současnosti se příliš dobře nevyrovnává s I/O chybami a vyčerpání volného místa může být kritické. Blíží se však do použitelného stavu - minimálně pro testování a benchmarky. Začlenění kódu do hlavní řady způsobí, že se na něj podívá více lidí a že se proti němu budou testovat různé změny v souborových systémech. Chris dává příklad toho, jak by to mohlo fungovat:

Pro příklad uveďme patche proudového zápisu [streaming write], které jsem do fsdevel zaslal minulý týden. Netestoval bych proti ext4 tak často, kdybych musel lovit v externích repozitářích jenom kvůli tomu, abych sehnal něco, co bude konzistentní se současným vývojovým jádrem. ext4 v hlavní řadě mi značně zjednodušuje práci.

Btrfs má agresivní plán, jehož cílem je vydání verze 1.0 v letošním roce. Cílem daného vydání je stanovit formát na disku tak, aby byly pozdější změny zpětně kompatibilní. Vzhledem k tomu, že 2.6.29 bude pravděpodobně vydáno někdy mezi začátkem a polovinou roku 2009, zdá se dost možné, že Btrfs bude do té doby "začleněníhodný", což znamená, že skutečně není předčasné o něm teď začít přemýšlet.

Přesouvání přerušení do vláken

Zpracování přerušení od hardwaru je hlavním zdrojem latence v jádře, protože ostatní přerušení jsou blokována, dokud zpracování probíhá. Z toho důvodu má realtime strom vlastnost nazývanou obsluha přerušení ve vláknech, jejíž cílem je minimalizovat čas běhu se zakázaným přerušením na holé minimum - vytlačením zbytku do jaderných vláken. Nejenom realtime jádra ale mají zájem o nízké latence, takže obsluha ve vláknech je navržena pro začlenění do hlavní řady.

Omezení latence v jádře je jednou z výhod, ale jsou zde i další. Největší je pravděpodobně omezení komplexity zjednodušením nebo vyhnutím se zámkům mezi "tvrdou" [hard] a "měkkou" [soft] částí obsluhy přerušení. Obsluha ve vláknech také usnadní ladění jádra a může časem vést k odstranění taskletů z Linuxu. Z těchto a pár dalších důvodů zaslal Thomas Gleixner sadu patchů, která přidává obsluhu ve vláknech, a "žádost o komentáře" k ní.

Tradičně se obsluha přerušení provádí v horní polovině [top half] (tj. "tvrdé" irq), která skutečně zareaguje na hardwarové přerušení, a spodní polovině [bottom half] (či "měkkém" irq), která je naplánována horní polovinou a která provede dodatečné zpracování. Horní polovina se vykonává se zakázanými přerušeními, takže je nutné, aby dělala tak málo, jak je možné, aby systém nepřestal reagovat. Obsluha ve vláknech by tuto práci ještě více zredukovala, takže horní polovina by sestávala z "rychlé ověřující obsluhy", která by se pouze ujistila, že přerušení pochází ze zařízení; pokud by to tak bylo, jednoduše by hardwaru potvrdila přerušení a řekla jádru, aby probudilo obsluhující vlákno.

V realtimovém stromě byly téměř všechny ovladače hromadně konvertovány tak, aby vlákna používaly, ale návrh v Thomasově patchi to nabízí volitelně - správci ovladače by mohli změnu provést, pokud by chtěli. Automatická konverze nejenom že u všech správců nebývá nutně populární, ale také má další nevýhodu, kterou Thomas popsal takto: Konverze přerušení na vláknové má smysl pouze v případě, že je kód obsluhy schopen ji využít integrováním funkce taskletů/softirq a zjednodušením zamykání.

Ovladač, který chce požádat o obsluhu přerušení ve vlákně, použije:

int request_threaded_irq(unsigned int irq, irq_handler_t handler,
                         irq_handler_t quick_check_handler,
                         unsigned long flags, const char *name, void *dev)

V podstatě jde o to samé jako v request_irq(), s přidaným quick_check_handler. Jak žádal Linus Torvalds na letošním Kernel Summitu, místo změn bezpočtu ovladačů, aby používaly nové request_irq(), byla zavedena nová funkce.

quick_check_handler ověří, jestli přerušení přišlo ze zařízení, a vrátí IRQ_NONE, pokud nepřišlo. Také může vrátit IRQ_HANDLED, pokud žádné další zpracování není potřeba, nebo IRQ_WAKE_THREAD, které probudí vlákno obsluhy. Aby se zjednodušila konverze na obsluhu ve vláknech, byl přidán ještě jeden návratový kód. quick_check_handler může být napsán předtím, než je handler konvertován; v takovém případě vrací IRQ_NEEDS_HANDLING (místo IRQ_WAKE_THREAD), což zavolá obsluhu obvyklým způsobem.

request_threaded_irq() vytvoří pro přerušení vlákno a vloží do něj ukazatel na struct irqaction. Ukazatel na struct irqaction byl navíc přidán do struktury task_struct, takže obsluhy mohou testovat příznaky action kvůli nově příchozím přerušením. Tato reference se také používá, aby se zabránilo pádu vlákna kvůli způsobení oops. Doteď byla jednou z mála stížností na návrh obava z plýtvání čtyř nebo osmi bytů v každé task_struct, která nepatří obsluze přerušení (tj. v drtivé většině). Strukturu by mohlo být možné rozdělit na dva typy, jeden pro jádro a jeden pro uživatelský prostor, ale není jasné, jestli to bude nutné.

Andi Kleen má obecnější obavu, že obsluha přerušení ve vláknech povede ke špatnému kódu: Abych byl upřímný, mám takový názor, že to v dlouhodobém měřítku podpoří špatně napsaný kód přerušení. Zdá se nicméně, že je v menšině. Komentářů bylo relativně málo a většina se zdála být pro - mnoho lidí možná čeká na konvertovaný ovladač, o kterém Thomas slíbil, že ho dodá "opravdu brzy". Pokud se neobjeví velké překážky, tak to vypadá, že strom linux-next bude dalším logickým krokem, možná následovaný začleněním do hlavní řady v 2.6.29

Diskuse k tomuto článku

[M. Lox]

…souborové systémy, stejně jako ovladače zařízení, jsou dostatečně oddělené od zbytku jádra, takže brzké začlenění nemůže příliš škodit. Určitý druh precedentu byl také nastaven brzkým "začleněním" ext4, i když to byla evoluce existujícího souborového systému ext3, zatímco Btrfs je zcela nový. Andrew Morton Chrise povzbudil, aby Btrfs dostal do linux-next okamžitě a začlenil ho do 2.6.29…

Vzpomínáte na Reiser4?

[CIJOML]

na vrahem vytvoreny fs sere pes a doufam, ze reiser dela v krimu defku

[Nikola Ciprich]

no tys tu chybel :-/

[stybla]

na vrahem vytvoreny fs sere pes ...

eh?

[Nikola Ciprich]

taky jsem si na to hned vzpomnel, ale tam byl problem v tom, ze reiser4 je o dost vice intruzivni, meni snad i veci ve VFS, atd. a Hans to svym pristupem taky zrovna nezlepsoval. ac me to velice mrzi, tak ted uz reiseru4 moc velke sance nedavam :(

[M. Lox]

Kdepak, nemění nic mimo svůj kód, rozhodně nic společného pro jiné části jádra a tak důležitého, jako je VFS. Jediným důvodem skutečně byl Hansův přístup, což však mnoho vývojářů vehementně popírá a schovává se za technické důvody. I kdyby tam však nějaké byly, tak tímhle prohlášením jejich váhu stejně popřeli.

[trekker.dk]

Kdepak, nemění nic mimo svůj kód, rozhodně nic společného pro jiné části jádra a tak důležitého, jako je VFS.

Právě naopak VFS obchází a duplikuje funkce.

Jediným důvodem skutečně byl Hansův přístup, což však mnoho vývojářů vehementně popírá a schovává se za technické důvody.

Pohádka o zlých vývojářích. Reiser4 byl revidován, Hans dostal seznam věcí, které nevyhovují a je potřeba je změnit. Pak začal vývojářům nadávat a nezměnil nic. Čiže: technické důvody tu byly první.

[M. Lox]

Právě naopak VFS obchází a duplikuje funkce.

1. Ale nemění nic mimo svůj kód, takže když ho při kompilaci vypneš, dostaneš jádro identické s neopatchovaným. Neexistuje důvod pro nezařazení takového kódu, jak dokazuje i Andrewova citace výše.
2. Jediný mně známý případ tohoto je cryptocompress, jehož obdobu, i když zatím méně propracovanou a silně nestabilní, obsahuje btrfs taky.

Pohádka o zlých vývojářích. Reiser4 byl revidován, Hans dostal seznam věcí, které nevyhovují a je potřeba je změnit. Pak začal vývojářům nadávat a nezměnil nic. Čiže: technické důvody tu byly první.

Právě o ten seznam tu jde. Vývojářům btrfs totiž IMHO nikdo nic takového nedal, protože jim řekli, že bugy budou odstraněny až v jádře, což je (mimo jiné) Linusova politika, se kterou já souhlasím. Hansovi bylo naproti tomu oznámeno, že R4 bude začleněn teprve až v něm žádné chyby nebudou.
Dále vezmi v úvahu, že R4 byl ve chvíli kdy ho Hans navrhl k začlenění již docela stabilní, zatímco btrfs je stále téměř nepoužitelný, ale přesto bude začleněn.

[trekker.dk]

Ale nemění nic mimo svůj kód...

To je ale fuk. Když se pokusíš začlenit kód, který obsahuje duplicitní funkce, tak s největší pravděpodobností pohoříš bez ohledu na to, jestli to je souborový systém, ovladač nebo změna správy paměti.

Vývojářům btrfs totiž IMHO nikdo nic takového nedal, protože jim řekli, že bugy budou odstraněny až v jádře, což je (mimo jiné) Linusova politika, se kterou já souhlasím. Hansovi bylo naproti tomu oznámeno, že R4 bude začleněn teprve až v něm žádné chyby nebudou.

Ano, protože v té době se to tak dělalo se vším. Politika začlenit opravdu brzo a chyby opravit až v jádře je stará pár měsíců.

Navíc zrovna u R4 nebylo vůbec jisté, jestli chyby budou opraveny. Vzhledem k tomu, že Hans prohlásil, že to tak je správně a ostatní jsou kreténi, dá se očekávat, že by s tím nehnul. A po zkušenostech s R3, na který se úplně vykašlal a jeho údržbu museli převzít jiní, se nedivím, že vývojáři nechtěli riskovat to samé znovu.

Dále vezmi v úvahu, že R4 byl ve chvíli kdy ho Hans navrhl k začlenění již docela stabilní, zatímco btrfs je stále téměř nepoužitelný, ale přesto bude začleněn.

To jo, ale do linux-next. O začlenění do hlavní řady v žádném případě není rozhodnuto.

[M. Lox]

Tak já to shrnu:

• Oba jsou do značné míry revoluční, obsahují novinky
• Oba obsahují jednu (a jedinou) fci, která by měla být jinde (komprese)
• Ani jeden z nich nemění cizí kód
• R4 je mnohem stabilnější
• Oba jsou aktivně vyvíjeny
• Bývalý vývojář jednoho z nich byl idiot

Když odečteme oblasti, ve kterých jsou oba stejné a ty, které jsou již záležitost minulosti, tak tu zbyde to, že je R4 stablinější, ale přesto není začleněn.

[trekker.dk]

To shrnutí je hezké, ale

Oba obsahují jednu (a jedinou) fci, která by měla být jinde

Tohle není tak úplně pravda - respektive rozhodně nebyla, když H. Reiser navrhoval začlenění.

Oba jsou aktivně vyvíjeny

Z čehož jeden PODSTATNĚ rychleji, že?

Když odečteme oblasti, ve kterých jsou oba stejné a ty, které jsou již záležitost minulosti, tak tu zbyde to, že je R4 stablinější, ale přesto není začleněn.

To by se o to někdo musel snažit. Reiser skončil u toho, že o vývojářích jádra prohlásil to, co o nich prohlásil a o další začlenění se nesnažil. Teď, když ho zavřeli, se o začlenění snaží někdo jiný, nicméně vzhledem k tomu, že btrfs může být za Reiser4 dostatečná náhrada, pochybuju o tom, že svůj záměr dotáhne do konce. Podporu ze strany ostatních vývojářů nicméně má.

[M. Lox]

Tohle není tak úplně pravda - respektive rozhodně nebyla, když H. Reiser navrhoval začlenění.

Poprvé možná, ale on to navrhoval vícekrát. Minimálně první dva pokusy se navíc obešly bez invektiv.

Z čehož jeden PODSTATNĚ rychleji, že?

Druhý je zase podstatně dál už teď

[alblaho]

To neprošlo ze dvou důvodů. Za prvé, vývojáři se nesmířili s některými vlastnostmi R4 jako třeba možnost otevřít si soubor jako adresář (není to košer, totiž ehm, POSIX). No a za druhé, Hans byl špatný komunikátor.

Btrfs má rozhraní standardní a jeho vývojáři nejsou sociopati. Takže bych v tom neviděl problém, ten kód je opravdu izolovaný, nic jiného neovlivní.

[M. Lox]

Zrovna tuhle vlastnost vyhodili, a, jak jsem už napsal, R4 taky nic mimo svůj kód nemění.

[stybla]

Vzpomínáte na Reiser4?

Vzpominam si hlavne na to, ze "communication failed" viz co napsali ostatni.

[al-Quaknaa]

Já ho třeba používám a nevím o jiném FS, na kterém funguje transparentní komprese tak snadno jako na reiser4 (mimo to, že je už tak dost rychlý). Na btrfs čekám hlavně proto, že reiser3 už začíná stárnout (nelíbí se mi jeho fragmentace při využití nad 80% a nemá žádné pokročilé funkce - snapshoty, komprese, šifrování), vypadá dobře a bude nejspíš lepší než ext*. I když žádný expert nejsem, že...

[alex]

Používám Reiser 4 nějakou dobu, i když nikoli v produkčním prostředí. Jsem s ním spokojen, rychlost při práci s malými soubory nemá konkurenci, stabilita výborná, přestože Reiser 4 není dokončen.

1) rozepře H. Reisera a vývojářů Linux kernelu: s Hansem není právě snadné vyjít, ale domnívám se, že v tomto případě je větší kus pravdy na jeho straně. Nakonec ten, kdo v diskusi reagoval iracionálně byl právě Ch. Helwig. Je škoda, že takoví lidé jsou zodpovědní za směr, kterým se Linux vydá. Hans asi udělal chybu, když se rozhodl svůj projekt implementovat v Linuxu a nevybral třeba některý z rodiny *BSD, situace mohla být asi zcela jiná...

2) Reiser4 pluginy: modularita je výborná věc, modulární software je flexibilnější, snadněji se debuguje, přidávají funkce... V oblasti file systémů to ale není běžná věc a navíc směr, kterým kráčí vývoj Linux kernelu je právě opačný, bohužel... Třeba VFS API (poprvé myslím implementováno v SunOS) takovou modularitu umožňuje, takže jakýkoli FS, který má toto API lze relativně snadno naportovat. Vše ostatní je (a měla by být) záležitost kódu samotného FS. V Linuxu se však stále více věcí implementuje obecněji přímo v kernelu (žurnály, schedulery...). Dle mého názoru je tento přístup chybný, jednak tím značně znesnadňuje portabilitu file systému do jiného operačního systému a naopak (příslušná část kódu nemusí být v jiném OS přítomna, resp. bude duplicitní v druhém případě). Za další klade překážky vývojářům v implementaci vlastních algoritmů (alokátorů, žurnálů, schedulerů...) a vnucuje jim vlastní kód. Tato snaha v konečném důsledku zredukuje file systémy na definici on-disk formátu...

3) současná podoba ReiserFS:  je (resp. spíše byl) pouhou částí vývojového projektu, který Hans Reiser zamýšlel. Jeho cílem měl být file systém se schopnostmi relační databáze. Obecně file systémy a databáze mají mnoho společného a mnohokrát se vývojáři file systémů nechali databázemi inspirovat (b-tree, transakce, logy - žurnály, indexy, cesta v čase - versioning jako v postgres nebo Oracle...), ale vždy šlo o nějaký malý subset toho, co dokáže skutečná databáze. Finální ReiserFS, Hansem občas zvaný Reiser SSN - Semi Structured Namespace, měl umět to, co dělá každá relační databáze. Klasický FS má rigidní hierarchický namespace (pravda rigidita není úplně striktní, jsou tu linky a rekurzivní adresáře), kdežto relační databáze má v zásadě plochý namespace (dobře má tabulky, ale to je interní struktura) a namespace hierarchizuje per dotaz podle toho, na co se uživatel ptá. Pokud mne zajímá např. kolik klientů z DB zákazníků koupilo kombinaci několika konkrétních předmětů zformuluji dotaz a DB údaje vyhledá, odfiltruje, zformátuje a vrátí pěknou tabulku přesně na míru tazatele. V kontextu file systému by to znamenalo, že pokud chci znát, které všechny písničky v mp3 na mém disku mají v titulu slovo "utopia" zformuluji dotaz (pomocí GUI nebo specifického příkazu) a FS vrátí seznam. Podobnou věc samozřejmě mohu udělat v klasickém FS třeba za pomoci find, s tím rozdílem, že můžu hledat jen podle názvu souborů nikoli podle názvů samotných skladeb (optimálně s užitím indexu) a pokud mám velkou mp3 kolekci budu na výsledek čekat týden... Podobné schopnosti měl mít (nebo bude mít???) WinFS, tam ale šlo o vrstvu nad NTFS a obávám se, že rychlost by nebyla právě ideální. Reiser 4 měl být storage vrstvou, která prostřednictvím vychytávek typu dancing trees, wandering logs, transakcí... atd. umožní efektivní a rychlou práci a la relační databáze v Reiser SSN. Lze tedy říci, že větší část projektu zůstala nerealizována... Večná škoda.

4) Jen na okraj: vypadá to, že doba rotujících disků jakožto převažujícíh medíí k ukládání dat se pomaličku chýlí ke konci. Pro ně byl ReiserFS projektován (listy b-tree jsou na disku umístěny v sousedních blocích a využívá se tak největší přednosti klasického disku - rychlosti v kontinuálním čtení/zápisu) a se jejich ústupem se ztratí i výhody ReiserFS. SSD disky nejsou penalizovány za náhodný přístup, ale preferují (podobně jako RAID-5) I/O ve větších a zarovnaných blocích. Vypadá to, že nás čeká velký comeback jiného druhu file systémů. Těch, co zažily nástup v 90. tých letech minulého století a přesto se nedočkali praktického užití - s malou výjimkou file systému Spiralog od Digital Equipment blahé paměti. Jde o log-structured file systémy.