Jaderné noviny 192

25. 11. 2002 | Leoš Literák | Jaderné noviny | 5019×

Pokus protlačit Reiser4 po zmražení jádra. EVMS mění směr. Testy IDE-CD. Stav zmražení nových vlastností.

Do konference přišlo celkem 1792 emailů, nejvíce psali Alan Cox, William Lee Irwin III a Andrew Morton.

Pokus protlačit Reiser4 po zmražení jádra, 39 emailů

Hans Reiser se pokusil přesvědčit Linuse Torvaldse, aby začlenil Reiser4 do řady 2.5 i po zmražení jádra vůči novým vlastnostem [LL: jak elegantně přeložit feature freeze?]:

Proč začlenit:

• dvojnásobná výkonnost (viz http://www.namesys.com/v4/fast_reiser4.html), bylo měřeno na zápisu a čtení adresáře s jádrem
• umožní testovat a měřit [benchmark] změny ve VM a VFS na nejrychlejším souborovém systému
• provádí všechny operace jako atomické transakce, takže například write() či truncate() se buď provedou kompletně nebo vůbec.
• poskytuje infrastrukturu pro atomické fs transakční API
• škálovatelné na velký počet CPU
• eliminuje pevnou velikost žurnálovací oblasti
• poskytuje pluginovou infrastrukturu. Tak bude možné vytvořit vlastnosti jako omezení či dědičnost v podobě pluginu. Nebo nové bezpečnostní atributy budou mít podobu souboru s pluginem.
• první funkční soupeř microsoftího projektu OFS. Žádný jiný linuxový souborový systém se ani nesnaží být alternativou OFS.

Jsme vzrušeni jak dramatickým nárůstem výkonnosti u atomických transakcí a infrastrukturou pluginů. Tato funkčnost zabila výkon u jiných souborových systémů. Jednou jsi [Linusi] souhlasil, že souborové systémy by měly mít 6 týdnů, co se VM/VFS stabilizuje. Je mi líto, že ti to musím připomenout. Reiser4 ale nemohl být hotov dříve. Doufám, že můj kolega domorodec se po mém návratu z lovu podívá na mamuta na mých zádech a odpustí mi, že jsem přišel pozdě na večeři, myslíce na ubohý a hladový MS kmen .

Linus napsal pár poznámek svědčících o respektu vůči Reiser4, nicméně se nevyjádřil, zda jej začlení. [LL: v originále se dále probírají technické detaily Reiser4]

EVMS mění směr, 36 emailů

Kevin Corry ohlásil:

Chceme oznámit důležitou změnu ve směrování projektu Enterprise Volume Management System.

Jak jistě víte, řada 2.5 byla zmražena pro nové vlastnosti a zdá se jasné, že jaderný ovladač EVMS nebude začleněn. Majíce toto na paměti rozhodli jsme se přepracovat administrační nástroje v uživatelském prostoru (Engine), aby pracoval s existujícími ovladači včetně device mapperu a MD.

Proč tato změna? Protože se EVMS nedostala do řady 2.5, jeho budoucnost se stala velmi nejistou. Mohli jsme pokračovat ve vývoji a dodávat patche vůči aktuálním jádrům. Dostali jsme spoustu užitečným komentářů a změn za poslední měsíc. Mohli jsme trávit čas nad změnami a opravami. Nicméně jedna věc nebyla zmíněna: do jádra integrovaný mechanismus vyhledávání EVMS svazků [volume]. Věříme, že i kdyby se vše ostatní vyřešilo, později bychom narazili na tento problém. Jasně, mohli bychom vyhledávání přesunout do uživatelského prostoru, pak by ale bylo obtížné odlišit ovladač EVMS od device mapperu, neboť oba provádějí podobné úkoly.

Navíc pak by nebyl důvod duplikovat kód MD, abychom poskytovali kompatibilitu s existujícími softwarovými RAIDy. Když se objevování svazků přesune do uživatelského prostoru, nástroje EVMS mohou být snadno přepsány tak, aby komunikovaly s existujícím MD ovládačem. Chceme zdůraznit, že tato změna nebyla rozhodnuta unáhleně, uvažovali jsme o ni již od Linuxového sympósia v Ottawě v červenci. V posledních týdnech se však ukázalo, že aktuální přístup není v souladu s tím, co jaderná komunita chce a tak jsme se začali zabývat náročností a důsledky změny.

Jak se to projeví u EVMS uživatelů? Ideálně nijak. Neplánujeme změny v uživatelském rozhraní. Změny budou transparentní. Stejné funkce, pluginy i schopnosti. Samozřejmě budou menší změny. Instalace bude mírně odlišná, neboť bude vyžadovat jiné volby v jádře. Řada 2.5 obsahuje vše potřebné, takže nebude třeba ji patchovat. Neboť device mapper nebyl ještě začleněn do řady 2.4, tak její uživatelé budou muset patchovat.

Důležitou odlišností ale bude přesun objevování svazků do uživatelského prostoru. Proč? I když například softwarový RAID stále provádí objevování v kernelu, trendem je přesun do uživatelského prostoru. Takže i RAID se jednou bude muset přizpůsobit. Nevýhodou je ztráta automatického objevení svazků při bootu. Aktivace svazku nyní vyžaduje zavolání utility, které musí být přidáno do init skriptů.

Toto přepnutí však komplikuje možnost mít root na EVMS svazku. To se dá vyřešit pomocí initramfs z řady 2.5, což poskytne snadnou metodu, jak na to. Prostě byste přidali nástroje z EVMS do initramfs. Uživatelé 2.4 musí vytvořit ram disk přes initrd. Postup je bohužel často specifický jednotlivým distribucím. Budeme se snažit poskytnout dostatečné instrukce.

Alan Cox napsal, že vyhození velkého kusu kódu je špatné [LL: jak přeložit it sucks?], nicméně [oni] jdou správným směrem. Výsledkem bude čistší framework. Alan ocenil, že udělali to, co je pro Linux nejlepší, přestože pro ně osobně to musí být hořké zklamání.

Alexander Viro také reagoval:

Toto rozhodnutí (přesunout kód do uživatelského prostoru a izilovat změny v jádře) určitě znamená z dlouhodobého hlediska méně práce - zvláště pro vývojáře EVMS. Je mnohem snadnější psát v uživatelském prostoru. Máte k dispozici runtime prostředí a to samo o sobě znamená moc. Není zde žádné omezení 8 KB na zásobníku. Je tu ochrana paměti. Nemusíte se obávat změn ve vnitřních strukturách jádra. A dá se zde mnohem snadněji debugovat.

Cílem je poskytovat funkčnost, ne být v jádře - to druhé znamená mnohem těžší život. Toto rozhodnutí vyžadovalo velkou odvahu - tleskám jim. Je úžasné, co udělali, mají můj respekt, že si zvolili správný směr a dokázali jej obhájit. Bravo. Hodně štěstí - opravdu. Vážím si jen několika lidí. Těchto lidí si vážím. Velmi.

Mike Diehl byl zklamán tímto vývojem, neboť EVMS se mu jevila jako dobrá alternativa k LVM. Matthias Andree se zeptal na stav LVM2. Joe Thornber odpověděl, že Sistina má nové stránky: http://www.sistina.com/.

Testy IDE-CD, 12 emailů

Adam Kropelin vzrušeně oznámil:

Včera jsem se nudil a tak jsem se rozhodl, že je ten správný čas otestovat ide-cd s cdrecordem. Většinou to fungovalo skvěle! Po upgradu cdtools šlo všechno hladce. Běžel jsem pod SMP + preempt a byl jsem schopen pálit rychlostí 12x při méně než 2% zatížení CPU po celou dobu.Kapacita vyrovnávací paměti nikdy neklesla pod 98%.

Skoro jsem byl zklámán, jak všechno jede a tak jsem se rozhodl to trochu vystresovat. Kompiloval jsem tedy jádro 2.5.46 příkazem make -j10 bzImage, zatímco jsem pálil a ono to opět fungovalo! Buffer nikdy neklesl pod 96%. (Stroj je 2x Xeon 450, 256 MB RAM).

A tak jsem paralelně při dalším pálení spustil dd if=/dev/zero of=foo bs=1M. Konečně se to povedlo Tento zápis přebil pálení a po vyčerpání vyrovnávací paměti se překvapivě objevilo oops.

Jens Axboe byl rád za tuto informaci a požádal o informaci o hardwaru. Adam poslal, že harddisk je sdc na integrovaném řadiči AIC7xxx, vypalovačka je hdc na sekundárním IDE kanálu. Ostatní disky nebyly během testu používány. Jens napsal, že u SCSI je velice snadné vyhladovět požadavky [starve requests]. Poprosil jej, ať nastaví maximální počet tagu na 2-4 a pak nebude schopen zabít pálení. Mimochodem, více než 4 tagy nezlepší výkonnost, zato riskujete příšerné výluky [latencies].

Stav zmražení nových vlastností, 14 emailů

Dave Jones zaslal verzi 0.10 jeho po-Halloweenského dokumentu, který popisoval nové vlastnosti v řadě 2.5 a některé nástrahy. Novou verzi dokumentu najdete na adrese http://www.codemonkey.org.uk/post-halloween-2.5.txt. Robert Love doporučil přidat nová systémová volání, ale Dave odpověděl, že si pohrával s tímto nápadem, ale patřil by spíše do nového dokumentu. Dave totiž chce, aby tento byl určen spíše uživatelům než programátorům.

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licenci GPL verze 2.

       

Komentáře