Jaderné noviny – 15. 2. 2011: Plán změn v MD (RAID)

28. 2. 2011 | Jirka Bourek | Jaderné noviny | 3855×

Aktuální verze jádra: 2.6.38-rc5. Citáty týdne: Linus Torvalds, Ingo Molnár. Plán změn MD. Řízení propustnosti CFS. Bezpečnostní moduly a ioctl().

Obsah

• Aktuální verze jádra: 2.6.38-rc5
• Citáty týdne: Linus Torvalds, Ingo Molnár
• Plán změn MD
• Řízení propustnosti CFS
• Bezpečnostní moduly a ioctl()

Aktuální verze jádra: 2.6.38-rc5

Současné vývojové jádro je 2.6.38-rc5 vydané 15. února. Objem patchů klesá (trochu) s tím, jak se jádro stabilizuje, takže není mnoho nových vlastností, ale zato se objevily nějaké důležité opravy chyb. Detaily najdete v kompletním changelogu.

Stabilní aktualizace: aktualizace 2.6.32.29 (115 patchů), 2.6.36.4 (176 patchů) a 2.6.37.1 (272 patchů!) se v současnosti revidují; lze očekávat, že vyjdou 18. února nebo později.

Citáty týdne: Linus Torvalds, Ingo Molnár

Takže nikdy nic neoznačujte jako „zastaralé“ [deprecated]. Jestliže se chcete něčeho zbavit, zbavte se toho a opravte místa, kde se to volalo. Neříkejte „někdo jiný by se toho měl zbavit, protože je to zastaralé.“

A ano, až se příště objeví tahle diskuze, odstraním tu sra*ku. Je to nemoc. Je to jenom stupidní způsob, jak říct „někdo jiný by tenhle problém měl vyřešit.“ Je to způsob, jak se vymlouvat. Je to svinstvo. Byla chyba s tím vůbec někdy začít.

-- Linus Torvalds

Hej, jestliže tohle stačí, aby bylo __deprecated odstraněno, začnu tu diskuzi hned zítra!!

-- Ingo Molnár

Plán změn MD

napsal Jonathan Corbet, 16. února 2011

Uživatele subsystému MD (více disků [multiple disk] či RAID) v Linuxu by mohl zajímat Plán změn MD, který zaslal správce Neil Brown. Poměrně detailně se tam píše o mnoha věcech, které plánuje pro MD; jeho slovy:

Co konkrétně chci tímto plánem vyřešit, je explicitní stanovení požadovaného řazení a vzájemných závislostí jednotlivých úkolů. Snad se tím zjednoduší jejich řešení ve správném pořadí a snad to bude znamenat, že vyplýtvám méně času říkáním „to je moc těžké, možná bych si místo toho mohl přečíst nějaké e-maily.“

Naplánováno je mnoho zlepšení. Log špatných bloků by mohl RAID polím umožnit dál fungovat i s vadnými bloky, aniž by bylo nutné okamžitě vyjmout vadný disk. Je zde varianta „výměny za běhu“, která by umožnila vložit nový disk před vyjmutím starého, takže by pole mohlo dál fungovat se všemi disky i v době, kdy se nový synchronizuje. Sledování oblastí, o kterých se ví, že neobsahují užitečná data, by omezilo náklady na synchronizaci. Mnoho navrhovaných vylepšení funkce „reshape“ (změna pole) má za cíl zvýšit robustnost a flexibilitu a umožnit vzít zpět mnoho operací. Zvažováno je i mnoho dalších funkcí; kompletní seznam najdete v Neilově zprávě.

Řízení propustnosti CFS

napsal Jonathan Corbet, 16. února 2011

Plánovač CFS se snaží co nejlépe rozdělit dostupný čas CPU mezi procesy, které o něj soupeří, tak, aby každý z nich CPU využíval přibližně stejně. Plánovač nicméně nebude trvat na rovnoměrném vytížení, když bude k dispozici volný čas CPU; místo toho, aby CPU bylo nečinné, rozdělí plánovač přebývající čas mezi procesy, které ho dokáží využít. Tento přístup dává smysl; nemá cenu omezovat spustitelné procesy, když CPU nikdo jiný stejně nechce.

Až na to, že přesně tohle někdy správce systému chce udělat. Omezení maximálního podílu na času CPU, který může proces (nebo skupina procesů) zkonzumovat, může být zapotřebí, když procesy patří zákazníkovi, který si zaplatil jenom za určité množství času CPU, nebo v situacích, kdy je nutné poskytnout striktní izolaci procesů, co se spotřeby zdrojů týče. Plánovač CFS tímto způsobem využívání CPU omezit neumí, ale tuto situaci mohou změnit patche řízení propustnosti CFS, které zaslal Paul Turner.

Patch přidává do mechanismu řídících skupin CPU dva nové soubory: cpu.cfs_period_us definuje periodu, za kterou se reguluje spotřeba času CPU skupinou procesů, zatímco cpu.cfs_quota_us řídí, kolik času CPU může skupina za tuto periodou spotřebovat. Administrátor tedy může omezit skupině dostupný čas CPU a také nastavit granularitu, s jakou bude tento limit vynucován.

Paulův patch není jediný, který by měl tento problém řešit; sada patchů tvrdých limitů CFS, jejichž autorem je Bharata B Rao, nabízí téměř stejnou funkcionalitu. Implementace je ale odlišná; tento patch se snaží využít kód omezující propustnost z realtime plánovače a limity vynutit s jeho pomocí. Paul vyjádřil své obavy z toho, jaká bude režie za tento kód a jak dobře bude fungovat v situacích, kde je CPU téměř naplno využito. Jeho obavy pravděpodobně vyhrály – od začátku roku 2010 nebyl patch tvrdých limitů znovu zaslán; zdá se tedy, že do hlavní řady se dostanou patche pro řízení propustnosti.

Bezpečnostní moduly a ioctl()

napsal Jonathan Corbet, 16. února 2011

Systém ioctl() volání má z mnoha důvodů špatnou pověst, většina z nich souvisí s faktem, že každý implementovaný příkaz je ve své podstatě nové systémové volání. Není možné mít nějakou efektivní kontrolu nad tím, co se v ioctl() stane a bez prohrabávání se spoustou starého kódu není u mnoha obskurních ovladačů dokonce ani možné zjistit, co se děje. Není tedy překvapením, že kód, který přidává nové ioctl() příkazy, bývá podrobován pečlivému zkoumání. Nedávno se ukázalo, že z ioctl() bychom měli být nervózní ještě z jednoho důvodu – nespolupracuje dobře s bezpečnostními moduly a SELinux s ním několik posledních let pracoval chybně.

SELinux funguje tak, že specifické pokusy o přístup porovnává s oprávněními, které má volající proces. Pro systémová volání jako je write() je tento typ přístupu zjevný – proces se pokouší do objektu zapisovat. U ioctl() nejsou věci tak jasné. V minulosti se SELinux pokoušel pracovat s ioctl() voláními tak, že se podívá na specifický přístup a pokusí se zjistit, co se proces ve skutečnosti pokouší udělat. Například příkaz FIBMAP (který načte mapu umístění bloků souboru) bude povolen, pokud má volající proces právo číst atributy souboru.

Tento přístup má několik problémů počínaje tím, že počet možných ioctl() příkazů je obrovský. I když se nebudeme zabývat obskurními příkazy, které implementuje jediný ovladač, snažit se je vyjmenovat všechny a zjistit, co vlastně dělají, to je cesta k šílenství. A je to horší v tom, že zamýšlené chování daného příkazu ještě nemusí souhlasit s tím, co ve skutečnosti v reakci na daný příkaz udělá specifický ovladač. Jediný způsob, jak zjistit, co udělá ioctl() příkaz, je vypátrat, který ovladač volání vyřizuje a jak. Vytvořit tuto funkcionalitu není úkol pro příčetné; udržovat ji by nebyl úkol pro nikoho, kdo chce příčetný zůstat. Vývojáři bezpečnostního modulu se tedy rozhlíželi po lepším způsobu.

Že jeden našli, si mysleli, když si někdo uvědomil, že kódy příkazů používané implementacemi ioctl(), nejsou náhodná čísla. Ve skutečnosti jsou to pečlivě složené 32 bitové hodnoty, které zahrnují i 8 bitové pole „typ“ (které přibližně identifikuje ovladač, který příkaz implementuje), číslo příkazu specifické pro ovladač, pár bitů čtení/zápis a pole pro velikost. Použít bity čtení/zápis vypadalo jako skvělý způsob, jak zjistit, jaký přístup ioctl() volání potřebuje, aniž by bylo potřeba příkazu porozumět. Do 2.6.27 tedy byl začleněn patch SELinuxu, který vytrhl kód rozpoznávání příkazů a jednoduše použil bity čtení/zápis v kódu příkazu, podle kterých určil, jestli má být specifické volání povoleno nebo ne.

Tato změna zůstala více než dva roky, dokud si Eric Paris nevšiml, že ve skutečnosti nedává smysl. Většina volání ioctl() zahrnuje předání datové struktury do nebo z jádra; tato struktura popisuje operaci, která má být provedena, nebo obsahuje data vracená jádrem – nebo obojí. Pole velikost v kódu příkazu udává velikost této struktury a přístupové bity udávají, jak bude k dané struktuře přistupovat jádro. Tyto dvě informace se v základním kódu ioctl() použijí ke zjištění, jestli volající proces má správná přístupová práva k paměti, na kterou míří předaný ukazatel.

Jak Eric upozornil, tyto bity neříkají nic o tom, co ioctl() volání udělá s objektem identifikovaným popisovačem souboru, který byl předán jádru. Volání předávající data pouze pro čtení může zformátovat disk, zatímco volání se zapisovatelnými daty se může jenom ptát na informace o hardwaru. Použít tedy bity čtení/zápis k určení, jestli volání má nebo nemá pokračovat, s největší pravděpodobností neposkytne žádné dobré výsledky. Když se to řekne takhle, je tento poznatek zjevný, ale tehdy si toho žádný vývojář pracující na bezpečnosti nevšiml.

Tenhle kód tedy musí zmizet – v době psaní tohoto článku ale v hlavní řadě jádra změněn nebyl. A to má jednoduchý důvod: nikdo neví, co by ho mělo nahradit – jak bylo řečeno výše, jednoduché vyjmenování příkazů a očekávaného chování také není řešením. Je tedy nutné vymyslet něco jiného a není jasné, co to bude.

Stephen Smalley poukázal na jeden přístup, jehož návrh byl zaslán již roku 2005. Tento patch vyžaduje, aby ovladače (a další kód implementující ioctl()) poskytly zvláštní tabulku spojenou s každým kódem příkazu, ve které by byly uložena práva potřebná k vykonání příkazu. V té době se objevily předvídatelné námitky: změnit každý ovladač v systému by bylo problematické, v implementacích ioctl() je bordel už teď, tabulky by nikdo neudržoval při změnách ovladače atd. Návrh byl tedy opuštěn; jeho návrat pravděpodobně nebude u nikoho populární, ale pravděpodobně není jiná možnost, jak opravdu sledovat, co příkaz ioctl() dělá. Tyto vědomosti má pouze kód, který ho implementuje, takže pokud je chceme využívat jinde, musíme je nějak exportovat.

Samozřejmě je tu alternativa, kde prohlásíme, že (1) s ioctl() jsou problémy a (2) s bezpečnostními moduly jsou problémy, takže bude možná lepší se prostě vzdát a doufat že ostatní kontroly přístupu a další kontroly, které mohou být zabudovány do samotného ovladače, budou dostatečné. Což je v podstatě řešení, které máme nyní.

       

Komentáře

[kip]

Ve čtvrtém odstavci od konce je záips.

[Petr Ježek]

Je to chyba kernelu? Že by překlep změnil informaci v dezinformaci?

[Laco]

cely linux je deprecated :)

[Jiří J.]

Osobně bych rád v MD viděl něco jako "syncni i přestože část raidu bude poškozena". Nedávno jsem narazil na případ RAID5, kdy při synchronizaci nového disku (předchozí zkolaboval) při nějakých 95% nahodil jiný disk read error. Pravděpodobně se jednalo jen o celkem malou část a přeskočení by sice způsobilo několikabajtovou ztrátu dat, ale pořád lepší, než současná situace - sync se zastaví a RAID má najednou 2 "failed" disky, takže je víceméně odepsaný.

Nakonec to vyřešil jen mdadm -C --assume-clean a specifikace disků ve správném pořadí.

Je mi jasné, že majitel tomu mohl snadno zabránit nákupem disků různých výrobců, pravidelnými měsíčními kontrolami nebo třeba RAIDem 6, ale i MD subsystém tu má co zlepšovat.

[ZiGi]

Ja by som zase rad videl blokovu cache na SSD, Myslim, ze to by posunulo MD do uplne inej ligy. Predstava, ze by som mohol mat 10TB pole, ktore by bolo aj lacne a aj rychle je neuveritelne lakava.