Jaderné noviny - 15 a 16/2008

21. 5. 2008 | Jirka Bourek | Jaderné noviny | 2611×

LogFS, škálovatelný filesystém pro flash zařízení. Oddělení uspání na disk a do paměti. Git 1.5.5, "k dispozici na obvyklých místech". 2.6.25-rc9, "Opravdu to nechci udělat". Chyby a byrokracie. Budget Fair Queuing IO plánovač. Chyba poškozující paměť opravena. 2.6.25, "Dlouho slibované".

Obsah

• LogFS, škálovatelný filesystém pro flash zařízení
• Oddělení uspání na disk a do paměti
• Git 1.5.5, "k dispozici na obvyklých místech"
• 2.6.25-rc9, "Opravdu to nechci udělat"
• Chyby a byrokracie
• Budget Fair Queuing IO plánovač
• Chyba poškozující paměť opravena, 2.6.25 se očekává dnes
• 2.6.25, "Dlouho slibované"

Následující obsah je © KernelTrap.

LogFS, škálovatelný filesystém pro flash zařízení

7. duben, originál

Jörn Engel zaslal šestou verzi patchů, které do linuxového jádra zavádějí jeho nový souborový systém LogFS pro flash zařízení. Zvýraznil některé oblasti kódu, které vyžadují další práci a do CC seznamu zařadil lidi, kteří by kód měli dále zhodnotit. Ohledně samotného LogFS napsal, že jednou z jeho výhod oproti ostatním řešením je vylepšený čas připojování a menší spotřeba paměti. LogFS má strom přímo na úložném médiu docela podobný struktuře ext2, takže časy připojování jsou O(1). Pokračoval tím, že flash je v hardwaru standardních PC stále běžnější a vysvětlil:

Mezi chováním flash paměti a pevného disku jsou velké rozdíly. Současným postupem pro používání flash pamětí je přidání emulační vrstvy a staromódního diskového souborového systému. Jak by se dalo očekávat, tohle uspořádání odstraní některé výhody, které mohou flash paměti oproti diskům nabídnout. Principiálně je možné dosáhnout s flashovým souborovým systémem většího výkonu než se současným emulačním přístupem, prakticky se ale naše souborové systémy tomuto teoretickému cíli ani neblíží. Ve svém současném stavu je tomu LogFS blíže.

 

Citát: vydáváme s nevyřešenými záležitostmi

Vždycky máme nějaké čekající/nevyřešené záležitosti a myslím si, že s tím, jak se zlepšují naše sledovací možnosti, bude jich pravděpodobně čím dál víc. Hodně hlášení o chybách se těžko reprodukuje (někdy i pro toho, kdo je hlásil) nebo skončí bez oprav atd. Takže ano, nakonec skončím u toho, že vydávám s nevyřešenými záležitostmi, ačkoliv se většinou snažím odhadnout, o jak závažný problém se jedná, a nevydávat, dokud nejsou vyřešeny velké problémy.

Linus Torvalds, zpráva z 8. dubna 2008 na Linux Kernel mailing list.

 

Oddělení uspání na disk a do paměti

8. duben, originál

Následující tři patche začínají práci na přepracování frameworku uspávání na disk a do paměti pro zařízení, psal Rafael Wysocki. Poznamenal, že první patch zavádí nové callback funkce pro uspávání na disk a do paměti, zatímco další dva implementují nové callbacky pro platformu a typy PCI sběrnic. V popisu prvních patchů v sérii dodal, že předchozí callbacky jsou postupně odstraňovány a vysvětlil proč:

Hlavní důvod, proč tohle udělat, je oddělit callbacky uspávání do paměti (známé jako S2RAM a standby) od callbacků hibernace tak, aby nové callbacky nepřijímaly argumenty a nová sémantika každého z nich byla jasně specifikována. To bylo navrhováno mnohokrát a mnoha lidmi, včetně samotného Linuse. Důvodem je, že pokud je v současném uspořádání zavoláno například ->resume(), je těžké určit, proč bylo zavoláno (např. je to probuzení z paměti, z hibernace nebo uspávání selhalo? atd.)

Druhým důvodem je snaha napsat callbacky tak, aby byly flexibilnější a ovladače zařízení mohly udělat víc, než jim současné uspořádání umožňuje. Pro příklad - některé ovladače mohou potřebovat zabránit registraci nových potomků zařízení, dokud nebyly vykonány jejich ->suspend() callbacky. Nebo mohou chtít vykonat nějaké operace, které vyžadují dostupnost jiných zařízení, se kterými neexistuje vztah rodič-potomek, aby se připravily na vykonání ->suspend() atd.

 

Citát: zbytečné, protože lidem, kteří mají rozhodnout, je to fuk

Teď tady řeknu do záznamu, že si myslím, že zahození zmrazovače [freezer] je hloupý nápad. Z toho důvodu momentálně zvažuji jeho zařazení do TuxOnIce od chvíle, kdy bude vyřazen z hlavní řady jádra. Je mi jasné, že kvůli tomu bude ještě méně pravděpodobné, že TuxOnIce bude začleněn, ale to už mě teď stejně nezajímá - je zbytečné zabývat se začleněním, když lidem, kteří mají rozhodnout, jestli bude něco začleněno, je to fuk.

Nigel Cunningham, zpráva z 1. dubna 2008 na Linux Kernel mailing list.

 

Git 1.5.5, "k dispozici na obvyklých místech"

9. duben, originál

Nejnovější vydání gitu, verze 1.5.5 s novými vlastnostmi, je k dispozici na obvyklých místech, oznámil správce Gitu Junio Hamano, tento vývojový cyklus jsme nechali jenom něco málo přes dva měsíce dlouhý, protože předchozí cyklus verze 1.5.4 trval mooooc dlouho.

Git je distribuovaný systém pro správu verzí, který byl původně napsán Linusem Torvaldsem v dubnu 2005 jako dočasná náhrada BitKeeperu, který Linus používal pro správu zdrojového kódu jádra od února 2002. Junio Hamano převzal správcovství Gitu v červenci 2005 a nástroj jako takový je nyní vcelku oblíbený dokonce i mimo vývoj jádra. Co se nejnovější stabilní verze týče, Junio zdůraznil některé ze změn:

• Dodává se s git-gui 0.10.1.
• Byla aplikována spousta patchů, které mají zvýšit portabilitu a pochází ze snahy portovat Git pro Solaris.
• 'git fetch' nad nativním protokolem gitu vytvářel jedno spojení, aby našel množinu vzdálených referencí, a druhé, aby skutečně stáhl balík dat. Nyní se pro tyto úkoly používá jenom jedno spojení.
• 'git commit' už nespouští lstat(2) víc, než je nutné.
• Skripty pro bash doplňování (v contrib) znají víc příkazů a voleb.
• Pro povolení všech barevschopných příkazů se používá všepostihující konfigurační proměnná 'color.ui', která nahrazuje jednotlivé, jako byly 'color.status' a 'color.branch'.
• Pomocná funkce pro příkazový řádek bash doplňování může vypisovat informace o probíhajících operací (např. merge, rebase atd.).
• 'git help' umí používat pro zobrazování manuálových stránek různé backendy, to lze nastavit použitím volby 'man.viewer'.
• 'git gui' jsme naučili automatickou kontrolu pravopisu.
• 'git checkout' a 'git remote' byly přepsáno do C.
• Dva konfliktní bloky, které jsou rozděleny krátkým úsekem stejných řádek, jsou nyní spojovány do jednoho většího bloku, aby se výsledek dal snáze číst.

 

Citát: Břemeno ladění

Já to vidím tak, že břemeno ladění a opravování chyb leží hlavně na vývojářích kódu, který nefunguje. Nemůžeš vinit uživatele za to, že používají kód, narazí na chybu a ohlásí ji. Uživatelé, kteří hlásí chyby, nám dělají velkou službu bez ohledu na svou schopnost nebo ochotu udělat víc práce, než je to počáteční hlášení.

Jesper Juhl, zpráva z 10. dubna 2008 na Linux Kernel mailing list.

 

2.6.25-rc9, "Opravdu to nechci udělat"

11. duben, originál

Opravdu to nechci udělat a ve skutečnosti jsem doufal, že 2.6.25 bude vydáno během minulého víkendu (což je důvod, proč je -rc9 o pár dní opožděné - doufal jsem, že nebude žádné), ale vydávám -rc9, oznámil Linus Torvalds jádro 2.6.25-rc9. Změny jsou poměrně malé (zkrácený log je přiložen) a 60 % z nich jsou aktualizace v m68k - většinou v defconfigu. A nějaké aktualizace dokumentace. Nicméně jsou tam také nějaké aktualizace síťových ovladačů (vynikají tg3 a bezdrátový hostap), nějaké pozdní patche pro XFS a aktualizace ovladače mvsas (ovladač mvsas je v 2.6.25 nový, takže nemůže dojít k žádným regresím ;). Zbytek jsou jednořádky a pár revertů.

Linus také objasnil, proč vydává další release candidate: Důvodem, proč nevydávám 2.6.25, je to, že někteří lidé dělají rámus kvůli problémům v nastavení slab/page-alloc. Chtěl jsem tento týden něco vydat, ale nezdálo se mi, že tato verze může být konečná.

Jinak řečeno si myslím, že i tak budu 2.6.25 vydávat někdy začátkem příštího týdne, protože prostě nemůžeme čekat donekonečna. V nějakém okamžiku tohle prostě budeme muset označit za problém v 2.6.25.x, aby vývojáři, kteří mají něco k začlenění do příští verze, mohli začít začlenovat.

 

Citát: Snažím se pást milion šílených opic

To jsem prostě chudák starý já, kdo se snaží pást milion šílených opic. Utekla jenom jedna.

Andrew Morton, zpráva z 12. dubna 2008 na Linux Kernel mailing list.

 

Chyby a byrokracie

14. duben, originál

Ve vlákně v mailové konferenci Linux Kernel byl diskutován proces, který se používá při hlášení, hledání půlením [bisecting] a opravování chyb. Byla to odezva na návrh, že některé problémy by bylo možné vyřešit zavedením nových procedur. Al Viro na to upozornil: Nějak se nám tu vyvíjí byrokracie. Tím myslím 'víc a víc způsobů, jak vytvářet činnost a nedělat přitom nic ani trochu užitečného.' Společně s tendencemi pracovat způsoby, které dávají smysl jenom té byrokracii, a neustále navyšovat počet pravidel.

Později ve vlákně mu přitakal David Miller a přidal: Výsledná 'byrokracie', ať ji chcete nazývat jakkoli, podrývá jednu ze základních věcí, díky které je zábava pracovat na jádře Linuxu. Tou je značně volná povaha - uvolněná a flexibilní. A to je významný úspěch vzhledem k tomu, kolik věcí se změnilo. Ten pocit je to, co přitáhlo mě. A vím, že přitahuje a pohlcuje další nové lidi.

Andrew Morton se pokusil vrátit diskuzi k původnímu tématu: Problém, který tu diskutujeme, je zjevně velké množství chyb, které v jádře jsou, zjevně velké množství nových chyb, které do něj přidáváme, a naší zjevnou liknavost je řešit. Al poznamenal, že část problému spočívá v tom, že git je tak efektivní při začleňování kódu: Patche, které přicházejí během začleňování (obzvláště ze stromu, který přebírá ze sekundárních), nejsou dostatečně viditelné. A v tu chvíli je už pozdě, protože člověk musí udělat něco monumentálně ošklivého, aby Linus vzal zpět [revert] velké začlenění. Něco v takovém měřítku, jako byl Velký IDE Bordel [Great IDE Mess] v 2.5...

Dalším návrhem bylo nahradit bugzillu něčím lepším, na což Andrew odpověděl: Výměna bugzilly za něco jiného by nepomohla. Skončíme u toho, že spousta lidí bude ignorovat dobrý systém pro sledování chyb tak, jak ignorovali špatný.

 

Citát: Neinvestovat potřebný čas

Každý argument, který tu napíšeš, proč bys neměl investovat potřebný čas do ladění chyby, se úplně stejně vztahuje na ty vývojáře, kterým tak rychle odsekáváš a od kterých chceš pomoci.

David Miller, zpráva z 11. dubna 2008 na Linux Kernel mailing list.

 

Budget Fair Queuing IO plánovač

15. duben, originál

Pracujeme na novém I/O plánovači, který je založen na CFQ, ve snaze o vylepšení předvídatelnosti a férovosti služby při zachování vysoké propustnosti, kterou již poskytuje, začal Fabio Checconi oznámení BFQ I/O plánovače. Plánování férového rozpočtu (BFQ) mění round-robin přístup CFQ, které plánuje časové úseky, na férové plánování rozpočtů sektorů. Přesněji je každé úloze přiřazen rozpočet udávaný v počtu sektorů místo v množství času a rozpočty jsou plánovány lehce modifikovanou verzí WF2Q+. Rozpočet přiřazený každé úloze se během času mění jako funkce chování té úlohy. Nicméně lze nastavit maximální hodnotu rozpočtu, kterou může BFQ každé úloze přiřadit.

Na čase založená alokace diskové služby, kterou používá CFQ, má požadovaný efekt, ve kterém každé aplikaci účtuje čas vyhledávání [seek time], jež způsobí. Nicméně tato alokace také trpí problémy s neférovostí vzhledem k procesům, které se snaží o co nejlepší využití šířky pásma disku. Ve skutečnosti dokonce dochází k tomu, že i když je dvěma procesům přiřazen stejný časový úsek, každý může obdržet různou šířku pásma v závislosti na tom, jak jsou jejich požadavky rozmístěny na disku.

Naproti tomu BFQ může poskytnout silné garance distribuce šířky pásma, protože přiřazené rozpočty jsou udávány v počtu sektorů. Navíc díky politice Round-Robin je CFQ charakterizováno nejhorším případem zpoždění (jitter) dokončení požadavku O(N), kde N je počet úloh, které o disk soupeří. Naproti tomu díky přesnému rozdělení služby vnitřního WF2Q+ plánovače BFQ vykazuje zpoždění O(1).

Jens Axboe reagoval příznivě: Fabio, začlenil jsem plánovač kvůli nějakému testování. Na první pohled kód vypadá skvěle, udělal jsi skvělou práci! Poznamenal, že plánovač se brzy objeví v -mm stromě a že by stálo za to zvážit spojení těchto dvou I/O plánovačů dohromady.

 

Citát: Běžná konvence

Když už mluvíme o konvencích, mohl bys ve svých mailech psát řádky kratší než 79 sloupců, aby se nezalamoval citovaný text? Narozdíl od tvého návrhu tohle skutečně je běžná konvence.

Al Viro, zpráva z 13. dubna 2008 na Linux Kernel mailing list.

 

Chyba poškozující paměť opravena, 2.6.25 se očekává dnes

16. duben, originál

Konečně jsem to našel... patch níže řeší chybu ve sparsemem a testovací systém teď bootuje správně, oznámil Ingo Molnár. Patch popsal tak, že opravuje poškození paměti a pád na 32bitových x86 systémech. Jestliže je !PAE x86 jádro nabootováno na 32bitovém systému s více než 4 GB paměti, pak voláme memory_present() se start/end, které jde mimo rozsah MAX_PHYSMEM_BITS. Přidal kousek kódu se smyčkou, která může poškodit paměť, podle toho, o jakou paměť se jedná, můžeme spadnout, chovat se divně nebo si chyby vůbec nevšimnout. Ingo pokračoval poznámkou, že chyba byla poprvé do jádra zanesena s podporou sparsemem v jádře 2.6.16:

Věřím, že to byl důvod, proč mnoho pokusů o nalezení chyby půlením selhalo: vzor chyby byl nestabilní a zdánlivě funkční jádra obsahovala poškození paměti také. Bylo čiré štěstí, že 2.6.24 'fungovalo' a 2.6.25-rc9 se porouchalo zcela zjevně.

Linus Torvalds odpověděl: Skvělá práce. Vydal jsem to a nechám to trochu - alespoň přes noc - povařit, abych zjistil, jestli v tom nejsou nějaké záležitosti typu hnědý-papírový-pytlík (buď v tomhle nebo v některých posledních změnách od Andrewa). Nicméně jsem rád a myslím si, že skutečné 2.6.25 vydám zítra.

 

Citát: Pivo zdarma

Kdokoliv, kdo správně uhodne metodu, kterou jsem našel přesné místo, které poškozovalo paměť, obdrží pivo zdarma, až se někdy potkáme :-).

Ingo Molnár, zpráva z 15. dubna 2008 na Linux Kernel mailing list.

 

2.6.25, "Dlouho slibované"

17. duben, originál

Dlouho bylo slibováno, ale teď je tady začal Linus Torvalds oznámení o vydání jádra 2.6.25 Zvláštní díky Ingovi, který našel a opravil ošklivě vypadající regresi, u které se ukázalo, že to vůbec není regrese, ale stará chyba, která se dříve neprojevovala spolehlivě. Jinak řečeno tohle byla právě poslední oprava regrese, kvůli které jsem čekal s vydáním. Ne že by nebyla také spousta dalších oprav, ale nebyly to věci, které by ve mě vzbudily zvláštní obavy.

Kompletní changelog z jádra 2.6.24 má 7,5 M, komprimovaný patch 12 M. Tuny a tuny se změnily, ale jestli jste sledovali -rc vydání, tak o velkých věcech už víte. Změny od posledního rc (-rc9) jsou poměrně malé a většinou pěkně triviální, zkrácený log je přiložen. Většinou jsou to jednořádky, trochu větší jsou nějaké aktualizace ovladačů (síť a usb) a síťování (ačkoliv hodně aktualizací ovladačů jsou věci jako nové ID atd.).

Více informací o nejnovějším vydání můžete nalézt na KernelNewbies wiki stránkce Linux 2.6.25.  

Citát: Dnešní nová architektura kvm

Dnešní nová architektura kvm je ia64, též známá jako Itanium 2. Jako s390 je nabízena pouze v gitovém stromu, nikoliv v tarballu. Jako hosté jsou podporovány Windows a Linux.

Avi Kiviti, zpráva z 16. dubna 2008 na Linux Kernel mailing list.

       

Komentáře

[trekker.dk]

Na první pohled kód vypadá skvěle, udělal jsi skvělou práci!.

Tečka na konci je navíc.

Ne že by nebyla také spousta další oprav, ale nebyly to věci, které by ve mě vzbudily zvláštní obavy.

...dalších...