Jaderné noviny – 1. 9. 2010: Zamyšlení nad stabilními jádry

23. 9. 2010 | Jirka Bourek

Články - Jaderné noviny – 1. 9. 2010: Zamyšlení nad stabilními jádry  

Aktuální verze jádra: 2.6.36-rc3. Citáty týdne: Thomas Gleixner, Greg Kroah-Hartman. Trocha čísel a zamyšlení nad stabilními jádry. Další přístup ke sjednocujícím souborovým systémům.

Obsah

• Aktuální verze jádra: 2.6.36-rc3
• Citáty týdne: Thomas Gleixner, Greg Kroah-Hartman
• Trocha čísel a zamyšlení nad stabilními jádry
• Další přístup ke sjednocujícím souborovým systémům

Aktuální verze jádra: 2.6.36-rc3

Současné vývojové jádro je 2.6.36-rc3, které bylo vydáno 29. srpna. Nevzpomínám si na nic zajímavého. Jako obvykle se jedná hlavně o aktualizace ovladačů (65 %), z čehož největší kus (podle počtu řádek) je odstranění staging ovladače, který není připraven k nasazení a nezlepšoval se. Na frontě ‚tohle možná vyvolá vyvolá nějaké nadšení‘ jsou také nějaké aktualizace drm radeon/nouveau. Všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: Jádra 2.6.27.53, 2.6.32.21, 2.6.34.6 a 2.6.35.4 vyšla 27. srpna. Jako vždy obsahují opravy v celém stromě. Údržba 2.6.34 touto aktualizací končí.

Citáty týdne: Thomas Gleixner, Greg Kroah-Hartman

SIGEV_THREAD je nejlepším důkazem, že celé posixové rozhraní pro časovače bylo navrženo pod vlivem omamných/psychotropních látek, jejichž názvy zde nebudou upřesněny.

-- Thomas Gleixner

Sáhl do prvního pytle, který byl již dosti ošoupaný a na sobě měl omšelý nápis „27“, vytáhl z něj jedno ze zbývajících jader a hodil ho skupince. Pár malých lidí v zadní části davu jádro chytilo a pomalu s ním odešli směrem k vesnici. Og se těmto lidem divil, neboť neustále spoléhali na to, že je staré jádro zase spasí, a odmítali přejít dále, protože k této verzi chovali jakousi podivnou úctu, které Og prostě nerozuměl.

-- Greg Kroah-Hartman

Trocha čísel a zamyšlení nad stabilními jádry

napsal Jonathan Corbet, 27. srpna 2010

Verzím hlavní řady jádra je věnováno mnoho pozornosti, ale jenom relativně málo uživatelů tato jádra používá. Místo toho mají jádra, která jim poskytli jejich distributoři, a ta jsou zase odvozena od stabilních jader. Praxe vydávání stabilních jader už je tu dobře přes pět let, takže je možná čas se podívat, jak funguje.

V březnu 2005, když komunita diskutovala způsoby, jak dostat důležité opravy uživatelům jader z hlavní řady, mluvilo se o samostatném stromě, který by obsahoval jenom opravy; Linus si tenkrát myslel, že něco takového je odsouzeno k nezdaru:

Řeknu ti, kde je problém: Nemyslím si, že bys našel někoho, kdo by byl ochotný starat se o tento paralelní strom s „pouze triviálními patchi“. Během několika týdnů by se zbláznil. Proč? Protože je to zatraceně složitý problém. Kde nakreslíš čáru? Co je akceptovatelný patch? A když to zkazíš, lidi si budou stěžovat hodně nahlas, protože jsi jim „slíbil“ jádro, které je lepší než hlavní řada. Jinými slovy téměř žádná sláva, žádné zajímavé problémy a rozhodně budou lidé, kteří ti budou nadávat do blbců a horších, pravděpodobně jednou týdně.

Po tak povzbuzujících slovech bylo jasné, že se někdo odhodlá a té práce se ujme; tím někým byli Greg Kroah-Hartman a Chris Wright. 4. března 2005 vydali 2.6.11 s celými třemi opravami. O více než pět let později na tom Greg (též známý jako „Og“) stále pracuje (Chris není, co se týče stabilních aktualizací, již nějakou dobu aktivní). Za tu dobu vypadá historie stabilních jader takto:

Jádro	Aktualizací	Změn
		Celkem	Na verzi
2.6.11	12	79	7
2.6.12	6	53	9
2.6.13	5	44	9
2.6.14	7	96	14
2.6.15	7	110	16
2.6.16	62	1053	17
2.6.17	14	191	14
2.6.18	8	240	30
2.6.19	7	189	27
2.6.20	21	447	21
2.6.21	7	162	23
2.6.22	19	379	20
2.6.23	16	302	19
2.6.24	7	246	35
2.6.25	20	492	25
2.6.26	8	321	40
2.6.27	53	1553	29
2.6.28	10	613	61
2.6.29	6	383	64
2.6.30	10	419	42
2.6.31	14	826	59
2.6.32	21	1793	85
2.6.33	7	883	126
2.6.34	5	599	120
2.6.35	4	228	57

V tabulce výše jsou tučně zvýrazněna jádra, která jsou stále podporována v době psaní tohoto článku (i když 2.6.27 se zjevně blíží ke konečné).

Na první pohled můžeme vyvodit několik závěrů. První je, že počet oprav, které se dostanou do stabilních aktualizací, se postupem času rozhodně zvýšil. Z toho by se dal učinit závěr, že jádra jsou čím dál tím víc zachybovaná. To se těžko měří, ale je také potřeba mít na paměti, že je tu další důležitý faktor: Jaderní vývojáři jednoduše směřují do stabilního stromu více oprav. Mnohem více vývojářů se dívá na patche a má přitom na paměti aktualizaci stabilních jader, takže jsou vcelku běžné návrhy na to, že daný patch by měl být zaslán i tímto směrem. Oproti době před několika lety se ztratí o mnoho méně patchů.

Ještě jeden faktor zde hraje roli: Původní definice toho, co je vhodné pro stabilní strom, byla velmi restriktivní; jestliže chyba jasně nezpůsobovala oops nebo bezpečnostní zranitelnost, do stabilního stromu se nedostala. Nyní ale máme aktualizaci 2.6.35.4 a v ní je mnohem širší spektrum „oprav“ včetně podpory pro laptop Acer rv620, opravy překlepů, zlepšení sledovacích bodů, aby powertop fungoval lépe, úpravu příliš optimistického čekání mutexu v cyklu, nový parametr pro ovladač emu10k1 a podporu oprofile pro nový procesor od Intelu. Tato zlepšení jsou určitě něčím, co si uživatelé stabilních jader přejí, ale rozhodně jdou mimo původní rámec.

Autor článku si také za poslední dobu povšiml, že si do stabilních aktualizací našly cestu regrese; vzhledem k objemu patchů, které tam míří, není občasná regrese žádné překvapení. Nicméně možnost, že se jich ve stabilních jádrech objeví více, trochu nahání hrůzu, takže doufejme, že se problém nezhorší.

Další fakt, který stojí za povšimnutí, je, že počet stabilních aktualizací pro většinu jader pomalu klesá; pět aktualizací za celou historii 2.6.34 je nejmenší počet vůbec, odpovídá to počtu aktualizací 2.6.13. A to navíc 2.6.34 dostalo kvůli bezpečnostním chybám o jednu aktualizaci více, než bylo plánováno. Je vcelku zjevné, že práce s takovým tokem patchů na čtyřech jádrech zároveň je náročná; Greg toho má na bedrech víc, takže mu možná dochází čas.

Kdo přispívá patchi do stabilních jader? Autor článku se rozhodl, že se trochu povrtá v datech; zvolil dvě jádra: 2.6.32, které se udržuje déle, protože ho používají „enterprise“ distribuce, a 2.6.34, protože je to nejnovější jádro, které již není dále udržováno. Zde jsou největší přispěvatelé pro obě:

Nejaktivnější přispěvatelé do stabilních jader

2.6.32 Greg Kroah-Hartman 36 2,0 % Daniel T Chen 32 1,8 % Linus Torvalds 23 1,3 % Trond Myklebust 23 1,3 % Borislav Petkov 23 1,3 % Ben Hutchings 21 1,2 % David S. Miller 20 1,1 % Theodore Ts'o 20 1,1 % Tejun Heo 20 1,1 % Dmitry Monakhov 20 1,1 % Takashi Iwai 18 1,0 % Ian Campbell 18 1,0 % Jean Delvare 17 0,9 % Henrique de Moraes Holschuh 17 0,9 % Yan, Zheng 17 0,9 % Zhao Yakui 17 0,9 % Alan Stern 17 0,9 % Al Viro 16 0,9 % Alex Deucher 15 0,8 % Dan Carpenter 15 0,8 %

2.6.34 Alex Deucher 14 2,8 % Joerg Roedel 14 2,8 % Tejun Heo 10 2,0 % Daniel T Chen 9 1,8 % Neil Brown 8 1,6 % Rafael J. Wysocki 8 1,6 % Linus Torvalds 7 1,4 % Greg Kroah-Hartman 7 1,4 % Alan Stern 7 1,4 % Jesse Barnes 7 1,4 % Trond Myklebust 7 1,4 % Ben Hutchings 7 1,4 % Tilman Schmidt 7 1,4 % Avi Kivity 7 1,4 % Sarah Sharp 7 1,4 % Ian Campbell 6 1,2 % Johannes Berg 6 1,2 % Jean Delvare 6 1,2 % Johan Hovold 6 1,2 % Will Deacon 5 1,0 %

Několik jmen na seznamu vypadá povědomě. Linus se již nikdy neobjevuje mezi největšími přispěvateli do hlavní řady, ale oprav pro stabilní jádra vytváří poměrně hodně. Další jména se v kontextu jádra vyskytují méně: Daniel Chen je například přispěvatel z komunity Ubuntu; jeho příspěvky se nejčastěji týkají toho, aby audiozařízení opravdu fungovala. Někteří lidé jsou ve výše uvedeném seznamu, protože zavedli chyby, které svými patchi opravují – být v této roli není tak velká pocta. Autor přiznává, že zde nedělal žádnou rigorózní studii, ale předpokládá, že lidé zmínění výše z větší části opravují chyby, které zavedl někdo jiný. Dělají tak důležitou a nedostatečně oceňovanou službu tím, že vylepšují vydané verze hlavní řady, aby vznikla jádra, která chce zbytek světa používat.

Také se můžeme podívat na to, kdo tuto práci podporuje:

Nejaktivnější přispěvatelé podle zaměstnavatele
2.6.32 (žádný) 275 15,3 % Red Hat 267 14,9 % Intel 194 10,8 % (neznámý) 175 9,8 % Novell 166 9,3 % IBM 95 5,3 % AMD 60 3,3 % Oracle 40 2,2 % Fujitsu 33 1,8 % Atheros 30 1,7 % Parallels 29 1,6 % Citrix 27 1,5 % (školství) 26 1,5 % Linux Foundation 24 1,3 % NetApp 23 1,3 % Google 23 1,3 % (konzultant) 20 1,1 % NEC 18 1,0 % Canonical 15 0,8 % Nokia 14 0,8 %	2.6.34 (žádný) 95 18,7 % Red Hat 61 12,0 % (neznámý) 58 11,4 % Novell 45 8,9 % Intel 43 8,5 % AMD 35 6,9 % IBM 17 3,3 % (školství) 16 3,1 % MontaVista 9 1,8 % Fujitsu 9 1,8 % ARM 8 1,6 % Citrix 8 1,6 % NetApp 7 1,4 % Oracle 7 1,4 % (konzultant) 7 1,4 % Linux Foundation 7 1,4 % Google 6 1,2 % Nokia 6 1,2 % NTT 5 1,0 % VMWare 5 1,0 %

Tato čísla poměrně dobře odpovídají příspěvkům do hlavní řady, obzvláště na prvních příčkách. O opravování chyb se říká, že to je práce, která slávu nepřináší, ale dobrovolníci vedou žebříček i tak.

Prvních deset vydání 2.6.x stabilní strom nemělo, což je nyní těžké si představit. V ideálním světě by se jádro hlavní řady vydalo až poté, co v něm nezbývají žádné chyby. Historie vývojových cyklů (mimo jiné) 2.3 a 2.5 nicméně ukazuje, že tento přístup ve skutečném světě nefunguje – přijde bod, ve kterém komunita musí vytvořit stabilní verzi a začít další cyklus. Stabilní strom to umožňuje, aniž by se tím ukončil přítok oprav do vydaného jádra.

Tabulky výše ukazují, že proces práce se stabilními jádry funguje dobře; směřuje do nich mnoho oprav a spolupracuje na tom celá komunita. Může však přijít okamžik, kdy bude komunita muset revidovat standardy pro patche, které jdou do stabilních aktualizací. V určitém okamžiku se také možná ukáže, že práce se správou těchto jader je příliš rozsáhlá na to, aby ji mohl dělat jenom jeden člověk. Nyní ale stabilní stromy zjevně dělají to, co mají; Greg zasluhuje velké uznání za to, že všechno klape tak dlouho a tak dobře.

Další přístup ke sjednocujícím souborovým systémům

napsal Jake Edge, 1. září 2010

Možnost vytvořit sjednocení dvou (nebo více) souborových systémů je vlastnost Linuxu, která je často požadována a která se nikdy do hlavní řady nedostala. Byly vyzkoušeny různé implementace (vizte pohled Valerie Aurory z roku 2009, 1. část, 2. část), ale žádná nepřekročila bariéru. V poslední době učinila pokrok sjednocená připojení [union mounts], ale stále je tam na čem pracovat. Miklos Szeredi nedávno zaslal sadu RFC patchů, které implementují hybridní přístup, jenž zahrnuje techniky na úrovni souborového systému i VFS.

Myšlenka za sjednocujícími souborovými systémy je poměrně jednoduchá, ale háček se schovává v detailech. Ve sjednocení je souborový systém připojen „nad“ jiným s tím, že obsah obou se projevuje jako jediný zkombinovaný souborový systém. Změny provedené v tomto souborovém systému se objevují v „horním“ souborovém systému a se „spodním“ se pracuje v režimu pouze pro čtení. Jedno běžné nasazení je souborový systém na médiu pouze pro čtení (např. CD), který nicméně uživatelům umožňuje zápis do horního souborového systému uloženého na zapisovatelném médiu (disk, flash).

Je tu ale spousta detailů, které vývojáře sjednocujících souborových systémů sužují, mezi ně patří práce se jmennými prostory, se smazanými soubory a adresáři, POSIXová definice readdir() a tak dál. Žádný není nepřekonatelný, ale jsou problematické a je ještě těžší je implementovat tak, aby se nenarazilo na technické stížnosti správců VFS.

Miklosův přístup spojuje implementace založené na souborových systémech, jako je unionfs a aufs, s implementacemi založenými na VFS. Pro soubory je open() předáno tomu souborovému systému, který soubor obsahuje, zatímco s adresáři se pracuje na úrovni vrstvy sjednoceného souborového systému. První verze dokumentace od Neila Browna práci souborů a adresářů nerozlišovala, ale Miklos to prohlásil za chybu. Přístup k adresářům se nikdy ostatním souborovým systémům nepředává a adresáře musí z různých důvodů přijít ze samotných sjednocených připojení.

Jak naznačil Neil ve svém dokumentu, většina akcí ve sjednocení se týká adresářů. Zde je přesnější říci, že se jedná spíše o sjednocení adresářových stromů než souborových systémů, protože není potřeba, aby stromy sídlily na různých souborových systémech. Teoreticky by nižší strom mohl být také sjednocení, ale současná implementace to nepřipouští.

Souborový systém používaný v horním stromě podporuje „důvěryhodné“ rozšířené atributy (xattrs) a také musí poskytovat platný d_type (typ souboru) v odpovědích readdir(), což vyřazuje NFS. Vybělení – tj. soubory, které existují ve spodním souborovém systému, ale z horního byly odstraněny – se řeší pomocí atributu „trusted.union.whiteout“. Podobně jsou řešeny neprůhledné adresáře, které neumožňují zobrazit obsah adresáře ve spodním stromě, používají atribut „trusted.union.opaque“.

Záznamy v adresářích se slučují podle poměrně jednoduchých pravidel: Jestliže je ve spodní i horní vrstvě záznam stejného jména, horní má vždy přednost, pokud oba nejsou adresáře. V takovém případě se vytvoří adresář ve sjednoceném připojení, který spojí záznamy z obou. Při vytvoření sjednoceného připojení se vytvoří spojený adresář z kořenů horního a spodního adresářového stromu; následující vyhledávání dodržují stanovená pravidla a vytvářejí spojené adresáře, které se podle potřeby cachují v dentry sjednocení.

Zápis do spodní vrstvy je řešen pomocí tradičního přístupu „kopírování výše“ [copy up]. Otevření souboru nebo změna jeho metadat tedy zkopíruje soubor do horního stromu. To může znamenat vytváření adresářů, pokud soubor leží na nižších úrovních adresářového stromu. Když je to hotovo, hybridní sjednocující souborový systém se souborem dál nepracuje, přinejmenším ne přímo, protože operace se předávají hornímu souborovému systému.

Sada patchů je relativně malá a dělá jenom málo změn ve VFS – kromě změny struct inode_operations, která má dopady v celém stromě souborových systémů. V současnosti prvek permissions() této struktury očekává parametr typu struct inode* – hybridní sjednocující souborový systém ale potřebuje mít přístup k datům specifickým pro souborový systém (d_fsdata), která jsou uložena v dentry, takže se parametr mění na struct dentry*. David P. Quigley tuto změnu zpochybnil s tím, že unionfs ani aufs ji nepotřebovaly. Valerie Aurora upozornila, že sjednocená připojení by potřebovala něco podobného, což společně s Neilovou dokumentací záležitost vyřešilo.

Zbytek patchů jsou víceméně malé změny. První přidává nový prvek do struktury struct file_operations, který je nazván open_other() a používá se k předávání volání open() do horní nebo spodní vrstvy podle potřeby. Další umožňuje souborovým systémům nastavit příznak FS_RENAME_SELF_ALLOW, takže rename() stále přejmenování vyřeší na interních nepravých [dummy] inodech, které souborový systém používá pro objekty, jež nejsou adresáře. Zbytek kódu (po odečtení změny permissions()) je sám nový souborový systém fs/union.

I když je pro tyto souborové systémy (nebo připojení) obvykle používán název „sjednocení“ [union], Neil poznamenal, že to není přesné, a navrhl, aby se místo toho použil „překryv“ [overlay]. Miklos nebyl proti s tím, že „overlayfs“ by dávalo větší smysl. Valerie s tím víceméně souhlasila a dodala, že sjednocená připojení byla v jedné verzi nazývána „zapisovatelné překryvy“ [writable overlays]. Zmatek plynoucí z mnoha použití „sjednocení“ v existujících patchích (lze splést s unionfs, sjednocenými připojeními), mohou být dalším důvodem k přejmenování.

Sémantika readdir() je pro hybridní sjednocení také trochu jiná. Změny sjednocených adresářů, když jsou tyto adresáře čteny, se neprojeví ve vrácených záznamech a pozice [offset] vrácené funkcí telldir() nemusí být ve sloučeném adresáři stejné při dalším volání. Seznam záznamů ve sloučeném adresáři se vytváří a cachuje při prvním volání readdir() a pozice jsou přiřazeny sekvenčně, jak jsou záznamy čteny. Z větší části není pravděpodobné, že by si toho mnoho aplikací všimlo, jak říká Neilova dokumentace.

Větší záležitost se týká toho, s čím bojují všechny implementace sjednocení: Jak řešit změny v nějaké vrstvě, které proběhly mimo kontext sjednocení. Jestliže uživatel nebo správce přímo změní souborové systémy, které jsou součástí spojení, objevuje se mnoho ošklivých okrajových případů. Vynutit, aby byl nižší souborový systém pouze pro čtení, je atraktivní řešení, ale není jednoduché to vynutit obzvláště pro souborové systémy jako NFS.

Mikklos by rád problémy odstranil definicí nebo našel nějaký způsob, jak vynutit požadavky, které sjednocení má:

Nejjednodušší způsob, jak se z toho dostat, by mohlo být prostě vynutit exkluzivní modifikaci souborových systémů na lokální úrovni podle stejné strategie, kterou používá sjednocené připojení. Pro NFS a další vzdálené souborové systémy můžeme

a) přidat způsob, jakým to vynutit
b) žít s následky, pokud nebudeme na úrovni systému nic vynucovat
c) zakázat, aby byly součástí připojení

O tomto problému se trochu diskutovalo a nedošlo se k žádným závěrům kromě toho, že je potřeba, aby změna mimo sjednocený souborový systém nezpůsobila souběh [deadlock] nebo zpanikaření jádra.

V některých ohledech hybridní sjednocení vypadá jako jednodušší přístup než sjednocená připojení. Jestli ale dokáží vyhovět Al Virovi a dalším správcům souborových systémů, to se ještě uvidí. Tak nebo tak to ale vypadá, že řešení chybějícího sjednocujícího/překrývajícího souborového systému v hlavní řadě se blíží.

Diskuse k tomuto článku

[Jirka]

Jak se testuje jadro? Pisi a spousteji se nejake unittesty?

[cronin]

Prvy odkaz vrateny Googlom po zadadani Linux Kernel testing: http://test.kernel.org

[Jirka]

Neni tech testu nejak malo?

[Heron]

Ach jo

Pokud někdo znáte odkaz na testy (něco jako 30 tisíc unit testů, platformních a bezpečnostních) a ne jen tuhle sbírku vtipů tak sem s tím.

[jehovista]

Posle se do Archu jako aktualizace.

[Petr Ježek]

Někdy mi to taky tak připadá a po -Syu zasakruji, ale od roll-on distra nelze nic jiného čekat než že jeho uživatelé budou aktivními bugtrackery... Ostatně v oblasti kernel modulů to tak vesměs je...

[JoHnY2]

Diky za to uzivatelum archu a gentoo. Muzem diky tomu mit celkem solidni jadra v distrech jako je fedora, suse a ubuntu.

[Jirka]

No Gentoo zrovna nema uplne nejnovejsi jadra (i kdyz je pravda, ze asi prichazeji rychleji nez do jinych distribuci). A protoze jadro se instaluje nezavisle na portage (z portage se instaluji jen zdrojaky a pripade genkernel), tak se obavam, ze vetsina uzivatelu Gentoo jede na starsich, neaktualnich jadrech.

[mepho]

No oficialne jadra ma relativne pozadu, ale v repozitaroch si mozes stiahnut jedno z 9 podporovanych jadier pricom vacsina je v 10+ verziach dozadu, nechyba vanilla, git(najnovsie, par hodin po vydani noveho developerskeho jadra su tam) atd. Na desktope nedam na zen kernel (s par gentoo patchmi) dopustit, subjektivne najresponsivnejsi, najlepsie konfigurovatelny kernel s profilmi pre desktop/server/custom).

[Jardík]

Včetně pár let starýho SW

[zz]

Jo kdyby, 2.6.32-24 mi na počítači neboonabootuje a právě podobný problém řeším... prý "Error 16: Inconsistent filesystem structure"

[Karry]

Testovano na lidech

[Yokotashi]

Treba timhle: http://ltp.sourceforge.net/

Yokotashi

chapadla.cz

[Michal Kubeček]

Stabilní aktualizace: Jádra … 2.6.34.6 … vyšla 27. srpna. … Údržba 2.6.34 touto aktualizací končí.

Asi ne tak úplně:

  mike@lion:~> uname -r
  2.6.34.7-0.2-desktop

[Asi překlep]

Teoreticky by nižší strom mohl být také sjednocení, ale současná implementace to nepřipouští.

Pokud je to opravdu myšleno tak, že strom by byl sjednocení a ne sjednocený, tak se omlouvám. Každopádně díky za tyhle články.

[marek_hb]

teď jsem zaregistroval "zen kernel" - má smysl ho instalovat? zkusil jsem ho na debianu a kromě o něco rychlejšího bootu jsem nic moc extra nepocítil - naopak, třeba při vytváření disku pro virtual box to na zenu trvalo 3 x déle a počítač se skoro nedal používat - na distribučním to trvalo minutu a se systémem se normálně dalo pracovat