Jaderné noviny – 25. 11. 2009

23. 12. 2009 | Jirka Bourek | Jaderné noviny | 3130×

Aktuální verze jádra: 2.6.32-rc8. Citáty týdne: Dan Williams, Frank Ch. Eigler, Matthew Garret. LogFS se vrací. Slučování snímků pro device mapper. Hledá se pomoc: Správce kbuild. Kdo napsal 2.6.32. Resynchronizace RAIDu podle žurnálu.

Obsah

• Aktuální verze jádra: 2.6.32-rc8
• Citáty týdne: Dan Williams, Frank Ch. Eigler, Matthew Garret
• LogFS se vrací
• Slučování snímků pro device mapper
• Hledá se pomoc: Správce kbuild
• Kdo napsal 2.6.32
• Resynchronizace RAIDu podle žurnálu

Aktuální verze jádra: 2.6.32-rc8

Současné vývojové jádro je stále 2.6.32-rc8 vydané 19. listopadu. Podle toho, jak si věci stojí, tohle pravděpodobně bude poslední -rc. Přál bych si, aby se více lidí podívalo na seznam regresí, ale v nějakém okamžiku prostě budu muset říci ,ok, čeho je moc, toho je příliš‘. Detaily lze nalézt v kompletním changelogu.

Během minulého týdne nevyšly žádné aktualizace stabilního jádra.

Citáty týdne: Dan Williams, Frank Ch. Eigler, Matthew Garret

WiFi ovladače ve staging obecně existují ve dvou příchutích: (a) stará vysušená žvýkačka pod stolem v kavárně (ovladače s budoucností) a (b) čerstvé zvratky toho děcka po opici na hodině matematiky (ty bez budoucnosti).

-- Dan Williams

Co je pro někoho matení, je pro jiného abstrakce.

-- Frank Ch. Eigler

Vytvořit linuxovou distribuci je těžké. Je potřeba řešit velký počet vzájemně propojených závislostí. Zabere spoustu času zjistit, jak do sebe všechno zapadá, a správně věci opravit místo přidávání hacků specifických pro zařízení často vyžaduje přepisování spousty kódu. Jsem si jistý, že Google na to časem přijde a také jsem si jistý, že největší část jejich práce je věnována uživatelskému rozhraní a ne infrastruktuře pod ním. Ale i tak neočekávejte, že budete moci nainstalovat Chromium OS na libovolný kousek hardwaru a ono to bude v blízké budoucnosti fungovat stejně dobře jako například Fedora.

-- Matthew Garret

LogFS se vrací

LogFs je projekt Jörna Engela s dlouhou historií, je to pokus vytvořit souborový systém pro současná úložná zařízení bez rotujících částí; naposledy se zde o něm hovořilo v květnu 2007. Od té doby se LogFS v podstatě ztratil z dohledu. Od 20. listopadu je nicméně LogFS zpátky a podle všeho připraven pro začlenění do hlavní řady. Jörn říká:

Logfs tu byl již několikrát. Linusovo poslední slovo bylo „zmiz a vrať se, až budou všechny změny formátu hotové“. Nebo přinejmenším něco podobného. Změny formátu jsou hotové. A dokonce ani nemám v úmyslu rozbít git-bisect pro kohokoliv, kdo bude dost bláznivý na to, aby logfs použil pro /.

Slučování snímků pro device mapper

Minulý týden se na LWN zabývali používáním snímků v Btrfs, které by mohly správcům systémů umožnit obnovu po problematických aktualizacích. Btrfs nicméně není v jádře jediný mechanismus pro vytváření snímků [snapshot]; device mapper to již umí nějakou dobu. Co v DM chybí, je možnost obnovit „původní“ (hlavní) zařízení do předešlého stavu, pokud je to zapotřebí. S pomocí device mapper v současné podobě tedy nelze vzít zpět nešťastnou aktualizaci bez vypnutí systému a zkopírování dat.

Tato situace by se brzy mohla změnit, možná dokonce již v 2.6.33. Mike Snitzer zaslal patche pro cíl sloučení snímku DM. Tento cíl jednoduše sloučí snímek zpět na původní zařízení, čímž obnoví stav tohoto zařízení do doby, kdy byl snímek pořízen. Správce systému tedy může vytvořit snímek těsně před aktualizací a pak se vrátí do stavu před ní, pokud se věci nepovedou.

Jedna hezká vlastnost je, že sloučení snímku zachová stav všech ostatních snímků v systému. Náš správce systému si tedy může vytvořit další snímek po nepovedené aktualizaci před návratem do původního stavu. Tento snímek bude po aktualizaci existovat i nadále, což umožní ručně si vybrat změněné soubory, které by měly zůstat zachovány poté, co je systém jako celek vrácen do původního stavu.

Správce DM Alasdair Kergon řekl Jonathanu Corbetovi, že tento kód krátce revidoval a že si možná v blízké budoucnosti najde cestu do linux-next.

Hledá se pomoc: Správce kbuild

Sam Ravnborg, po dlouhou dobu správce jaderného subsystému pro překlad (kbuild), oznámil svůj úmysl se této funkce vzdát. Dělal jsem to čistě jako koníčka a rodina (3 děti atd.) + práce mě potřebují, takže dělat správce kbuild najednou nebyla zábava, ale povinnost. Není jasné, kdo ho nahradí. Samovi je vhodné poděkovat, protože po sobě zanechává systém pro překlad jádra v mnohem lepším stavu, než v jakém k němu přišel.

Kdo napsal 2.6.32

V době psaní tohoto článku se zdá, že 2.6.32 se zdá být připraveno k vydání někdy začátkem prosince. To znamená, že je čas podívat se na kód, který se do tohoto jádra dostal, a odkud přišel. Byl to další aktivní cyklus, ve kterém se do hlavní řady dostalo mnoho změn.

Konkrétně je v době psaní tohoto článku (krátce po vydání 2.6.32-rc8) 2.6.32 výsledkem 10 767 neslučovacích sad změn zaslaných 1 229 vývojáři. Tyto změny přidaly celkem 1,17 milionů řádek a odstranily 611 000 řádek, čistý přírůstek je tedy 559 000 řádek kódu. Podle zpráv o regresích od Rafaela Wysockiho tento vývojový cyklus do jádra zavedl celkem 86 regresí – o něco méně, než jsme viděli v 2.6.31. Od doby zaslání této zprávy se počet nevyřešených regresí rychle snižoval, bez řešeních jich je ještě 25.

Kdo tedy všechny tyto regrese řádky kódu přidal? Statistiky pro tento vývojový cyklus vypadají následovně:

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

Podle sad změn Greg Kroah-Hartman 202 1,9 % Johannes Berg 180 1,7 % Bartlomiej Zolnierkiewicz 164 1,5 % Mark Brown 154 1,4 % Paul Mundt 139 1,3 % Takashi Iwai 139 1,3 % Alan Cox 129 1,2 % Roel Kluin 115 1,1 % Luis R. Rodriguez 105 1,0 % Dan Williams 86 0,8 % Tejun Heo 84 0,8 % Herbert Xu 81 0,8 % Peter Zijlstra 80 0,7 % Ingo Molnar 77 0,7 % Julia Lawall 77 0,7 % Steven Rostedt 73 0,7 % Magnus Damm 72 0,7 % Joe Perches 71 0,7 % Joerg Roedel 70 0,7 %

Podle změněných řádků Greg Kroah-Hartman 174427 11,5 % Bartlomiej Zolnierkiewicz 108056 7,1 % Mauro Carvalho Chehab 62719 5,2 % Jing Huang 49189 3,2 % Forest Bond 45009 3,0 % Ben Hutchings 37418 2,5 % Eilon Greenstein 28008 1,8 % Mark Brown 24516 1,6 % Brian Swetland 22775 1,5 % Hank Janssen 19681 1,3 % Leo Chen 17458 1,2 % Palash Bandyopadhyay 16790 1,1 % Alan Cox 16466 1,1 % Mithlesh Thukral 15173 1,0 % Jerome Glisse 14343 0,9 % Michael Chan 13415 0,9 % Martyn Welch 12480 0,8 % Iliyan Malchev 12172 0,8 % Jesse Brandeburg 11051 0,7 %

Jak už se stalo tradicí, Greg Kroah-Hartman a Bartlomiej Zolnierkiewicz se objevují na prvních příčkách. Většina Gregovy práce má co do činění s pročišťováním ovladačů „hv“ od Microsoftu. Jeho rozpoložení během tohoto procesu lze nejlépe posoudit ze zpráv u commitů, které většinou vypadají jako tato:

Linuxové jádro nemá struktury pojmenované velkými písmeny, neradi křičíme na programátory, oni jsou potom naštvaní. Místo toho je uklidňujeme malými, kulatými písmeny, které u nich navozují příjemnou, poddajnou náladu a díky kterým jsou produktivnější, šťastnější a vůbec jim umožňují žít kvalitnější život.

Greg také ze stromu staging odstranil několik ovladačů, což jádro zmenšilo o více než 100 000 řádek.

Většina Bartlomiejovy práce je také ve stromu staging a většinou se týká opravování série nepříliš milovaných ovladačů pro bezdrátová síťová zařízení. Tyto patche jsou poněkud kontroverzní; vývojáři bezdrátového síťování by byli raději, aby se daná snaha věnovala jiné sadě ovladačů, které nebudou ve staging. Tyto ovladače ale ještě nejsou připraveny k nasazení, takže mezi tím lidé používají ovladače ve staging. Bezdrátové ovladače jsou také centrem práce Johannese Berga; na mnoha místech vylepšil subsystém mac80211 a konfigurační rozhraní cfg80211. Mark Brown dále přispívá velkým množstvím kódu podporujícího komponenty Wolfson Micro a Paul Mundt je stále aktivní jako správce Super-H.

Co se sloupečku „podle změněných řádek“ týče, Mauro Carvalho Chehab přispěl spoustou patchů jako správce Video4Linux2. Jing Huang přispěl SCSI ovladačem Brocade BFA FC a Forest Bond přidal do stromu staging bezdrátový ovladač VT6656.

Vývojáři pracující na 2.6.32 byli podporováni (přinejmenším) 196 zaměstnavateli. Nejaktivnějšími společnostmi tentokráte byly:

Nejaktivnější zaměstnavatelé 2.6.32

Podle sad změn (žádný) 1845 17,1 % Red Hat 1028 9,5 % (neznámý) 933 8,7 % Intel 888 8,2 % Novell 662 6,1 % IBM 603 5,6 % Oracle 319 3,0 % Renesas Technology 264 2,5 % AMD 251 2,3 % Nokia 204 1,9 % Fujitsu 201 1,9 % Atheros Communications 197 1,8 % (konzultant) 195 1,8 % (školství) 167 1,6 % Texas Instruments 155 1,4 % Wolfson Micro 153 1,4 % Broadcom 149 1,4 % HP 130 1,2 % Analog Devices 124 1,2 % Pengutronix 119 1,1 %

Podle změněných řádek (žádný) 282017 18,6 % Novell 256808 16,9 % Red Hat 150781 9,9 % Broadcom 84904 5,6 % Intel 79267 5,2 % (neznámý) 77122 5,1 % Brocade 49189 3,2 % Logic Supply 45165 3,0 % Google 40936 2,7 % IBM 29616 2,0 % Wolfson Micro 25577 1,7 % Texas Instruments 24824 1,6 % Renesas Technology 24507 1,6 % Nokia 24192 1,6 % Microsoft 19696 1,3 % Oracle 19410 1,3 % (konzultant) 18774 1,2 % Conexant 16790 1,1 % LinSysSoft Technologies 15173 1,0 % GE Fanuc 12495 0,8 %

Oko pozorného čtenáře si okamžitě všimne faktu, že Red Hat spadl pod 10 % celkového počtu změn – poprvé od vývojového cyklu 2.6.21 z počátku roku 2007. Celkový počet změn od Red Hatu je nicméně v tomto cyklu jenom o málo menší než obvykle; stalo se to, že jiné firmy začaly náskok dohánět.

Je zde několik dalších zajímavých záznamů. Google je často kritizován za to, že nepřispívá ničím nazpátek, ale tato společnost je tentokrát zdrojem slušného množství kódu, který se dostane do 2.6.32. Velká část z toho byla podpora pro platformu telefonu HTC „Dream“ (též známo jako G1 či ADP1, vizte T-Mobile G1 s Google Android), ale Google také přispěl do kontrolních skupin, ext4, správy paměti, IPVS a libata. A někdo by možná nikdy nečekal, že se v seznamu největších přispěvatelů do jádra objeví Microsoft, ale ovladače hv jej do něj v 2.6.32 dostaly.

Počet podpisů se od předchozích cyklů nemění:

Počet neautorských podpisů v 2.6.32
Jednotlivci David S. Miller 996 10,2 % John W. Linville 994 10,2 % Greg Kroah-Hartman 788 8,1 % Andrew Morton 786 8,1 % Ingo Molnar 501 5,1 % Mauro Carvalho Chehab 398 4,1 % James Bottomley 310 3,2 % Len Brown 188 1,9 % Paul Mundt 171 1,8 % Russell King 165 1,7 %	Zaměstnavatelé Red Hat 3606 37,1 % Novell 1309 13,5 % Intel 906 9,3 % Google 793 8,2 % (žádný) 445 4,6 % IBM 384 3,9 % (konzultant) 274 2,8 % Renesas Technology 180 1,9 % Wolfson Micro 155 1,6 % Oracle 138 1,4 %

Pokud něco, pak se správci subsystémů shlukují víc než kdy dříve. Plné 2/3 patchů přicházející do jádra prochází pod rukama vývojářům pracujících pro pouhé čtyři firmy.

Na Jaderném summitu 2009 se jeho účastníci shodli, že i když zlepšení jsou možná vždy, proces jako celek funguje dobře. Obraz, který si lze udělat z těchto čísel, naznačuje stejný závěr: Stroj vyvíjející linuxové jádro nadále absorbuje masivní množství změn od široké vývojové komunity, přičemž produkuje stabilní a více funkcemi vybavená jádra.

Resynchronizace RAIDu podle žurnálu

Úložné technologie RAID 4, 5 a 6 jsou navrženy tak, aby chránily proti selhání jednoho disku (RAID 6 chrání proti selhání dvou disků – pozn. překl.). Bloky dat jsou rozmístěny na poli a pro každý pruh [stripe] se na jednom z disků uloží jeden paritní blok. Pokud jeden z disků selže, ztracená data lze obnovit použitím zbývajících disků a paritních informací. Tento mechanismus si ale hůře poradí s pády systémů a výpadky napájení, což správce pole nutí vybírat si mezi rychlostí a spolehlivostí. Nový mechanismus nazvaný „žurnálem vedená resynchronizace“ může lidem zjednodušit život, ale jenom jestli se opravdu dostane do jádra.

Problém je v tom, že data a paritní bloky se musí aktualizovat atomicky; pokud se rozejdou, pole již nemá možnost obnovit ztracená data; dokonce je možné, že v takovém případě vrátí data chybná. Drahá pole používají záložní baterii, která zajišťuje, že aktualizace není přerušena v polovině, ale řešení pomocí softwarového RAIDu tuto možnost často nemají. Takže když systém spadne – nebo vypadne napájení – během aktualizace RAID svazku, svazek může být poškozen. To lidé od počítačů z nějakého důvodu většinou považují za Špatnou Věc.

Je několik způsobů, jak toto riziko omezit. Jedním je provést kompletní prohledání RAID svazku po pádu s tím, že se opraví všechny částečně aktualizované pruhy [stripes]. Problém je zde v tom, že (1) správná oprava nekonzistentního pruhu nemusí být vždy zjevná a (2) tento proces může trvat dlouho. Dost dlouho na to, aby uživatelé začali vzpomínat na dny rychlých a spolehlivých disket.

Alternativní přístup je zavést do RAID vrstvy nějaký typ žurnálování. Implementace RAID si může na úložišti odložit nějaké místo, kam bude zapisovat pruhy (pravděpodobně ne data, ale jenom čísla pruhů, které se používají) před změnou na skutečném poli. Tento přístup funguje a dokáže obnovit spadlé pole bez kompletního prohledávání, ale za určitou cenu: Žurnálování může významně zpomalit fungování pole. Zapisování do žurnálu musí být synchronní, jinak nelze spoléhat na to, že funguje, takže zapisování je najednou mnohem pomalejší, než bylo. Vzhledem k tomu není překvapení, že spousta správců RAID vypne žurnálování na úrovni RAID a tráví spoustu času doufáním, že se nic nepokazí.

Před několika lety Timothy E. Denehy, Andrea C. Arpaci-Dusseau a Remzi H. Arpaci-Dusseau publikovali pojednání, ve kterém popsali lepší způsob nazvaný „žurnálem řízená resynchronizace“. Současné souborové systémy žurnálují samy; proč nepoužít jejich žurnál tak, aby sledoval i RAID? Používat jeden žurnál musí být levnější než používat dva – obzvlášť když uvážíme, že kromě jiných věcí musí žurnál RAIDu sledovat i změny v žurnálu souborového systému. Jediný problém je v tom, že vrstvy RAID a souborového systému komunikují pomocí relativně úzkého API blokové vrstvy; používání žurnálování souborového systému ke sledování informací na úrovni RAID má potenciál vrstvy významně promíchat.

Implementace žurnálem řízené resynchronizace Jodyho McIntyra přidává do souborového systému ext3 nový režim „declared“. Když je zapisován žurnál, přidá se k němu nový „deklarační blok“, který přesně popisuje, které bloky se mají na úložném zařízení zapsat. Tyto bloky jsou poté zapsány s novým BIO příznakem, který říká, že souborový systém přebírá zodpovědnost za to, že pruh synchronizuje, pokud se něco pokazí; to umožňuje úložné vrstvě na tento problém zapomenout. Pokud systém spadne, souborový systém najde tyto deklarační bloky v žurnálu; poté může provést (novou) operaci BIO_SYNCRAID, kterou požádá úložný subsystém o resynchronizaci specifických pruhů, které obsahují vyjmenované bloky.

Výsledkem by mělo být to nejlepší z obou světů. Cena za přidání dalšího bloku do žurnálu souborového systému je mnohem menší než zajišťovat toto žurnálování ve vrstvě RAID; Jody tvrdí, že postih na výkonnosti je 3-5 % oproti 30 % mechanismu bitové mapy plánovaných zápisů [write-intent bitmap] v MD. Resynchronizace po pádu by nicméně měla být poměrně rychlá, protože bude stačit podívat se jenom na ty bloky v poli, které byly právě modifikovány. Jediný problém je, že to vyžaduje přidání specifické podpory do vrstvy souborového systému, takže každý souborový systém by bylo nutné modifikovat odděleně. Také je potřeba vyřešit, jak tuto techniku použít u souborových systémů, které pracují bez žurnálování (například Btrfs.)

Pak je zde ještě jeden malý problém. Na této funkci se pracovalo v Sunu jako na způsobu, jak vylepšit výkonnost se souborovým systémem Lustre. Jody ale poznamenává:

Bohužel jsme zjistili, že tyto patche NEJSOU pro Lustre použitelné. Proto na nich již nebudu pracovat. Zasílám je pro případ, že by byly užitečné jako výchozí bod práce někoho jiného.

Tato série patchů je tedy nyní opuštěna. Zdá se, že by její funkcionalita mohla být uživatelům softwarového RAIDu užitečná, takže doufejme, že ji někdo převezme a bude na ní pracovat dál. Bez nového vývojáře budou správci softwarových RAIDů stále čelit nepříjemnému rozhodování.

       

Komentáře

[kralyk z abclinuxu]

No, nevim kdy přesně Sam Ravnborg ke kbuildu přišel, ale každopádně odved dobrou práci, alespoň myslim. Si vzpomínám na překlady jádra někdy ve verzi 2.4.x (kde x je poměrně malé), to byl děs. Trvalo to dlouho, bylo to nepřehledný, atd... (nevim, jestli tam tou dobou Sam byl nebo ne...)
Překládat jádro teď je radost. Doufám, že to po něm přebere někdo kompetentní.