![[Ric Wheeler]](/images/clanky/bourek/ric-wheeler.jpg)
Portál AbcLinuxu, 6. května 2024 03:35
Aktuální verze jádra: 2.6.36-rc1. Citáty týdne: Christian Hammond, Paul McKenney, Valerie Aurora, Al Viro. Poznámky z Bostonského minisummitu Linux Power Management. Poznámky z úložné koleje LSF. K dispozici jsou prezentace z KVM Forum. Testování crypto ovladačů při bootu. Závěr začleňovacího okna 2.6.36. Miliarda souborů v Linuxu. Konec blokových bariér.
Současné vývojové jádro je 2.6.36-rc1 vydané (bez oznámení) 15. srpna. Od shrnutí z minulého týdne bylo začleněno mnoho patchů; nejvýznamnější vizte níže. V krátkém shrnutí řekněme, že v tomto vývojovém cyklu přibyl bezpečnostní modul AppArmor, nový mechanismus uspávání, který by mohl – ale nemusel – vyhovovat potřebám projektu Android, sada ovladačů LIRC pro infračervené ovladače, nový zabiják při nedostatku paměti a háčky pro fanotify sloužící aplikacím pro odstraňování malwaru. Kdo chce znát všechny detaily, k dispozici je mu kompletní changelog.
Od 2.6.36-rc1 bylo začleněno pár patchů; mezi ně patří patch škálovatelnosti VFS Nicka Piggina. Na tyto patche se blíže podíváme příští týden.
Stabilní aktualizace: Jádra 2.6.27.51, 2.6.32.19, 2.6.34.4 a 2.6.35.2 byla vydána 13. srpna. Greg k nim říká: Už mě unavuje, že se lidé pokouší moje slova rozebírat, jako bych byl předseda Federálních rezerv. Prostě mazejte aktualizovat. Naši analytici věří, že to znamená, že trh s dluhopisy je nervózní, úrokové sazby budou stabilní a pravděpodobně jsou k dispozici důležité opravy.
Greg také poznamenává, že aktualizace 2.6.34 se blíží ke konci a plánuje se již jenom jedna. V době psaní tohoto článku se reviduje další aktualizace 2.6.27; budoucnost 2.6.27 také není moc dlouhá, protože Greg již nemůže na žádném hardwaru, který má k dispozici, nabootovat tak staré jádro.
Předtím vyšly 10. srpna aktualizace 2.6.27.50, 2.6.32.18, 2.6.34.3 a 2.6.35.1.
-- Jazykové lekce Ala Viro
Několik vývojářů, kteří se zabývají správou napájení v Linuxu, se 9. srpna těsně před konferencí LinuxCon setkalo na minisummitu v Bostonu. Bylo diskutováno mnoho témat včetně výkonnosti uspávání, přístupu Androidu a MeeGo ke správě napájení a dalších. Len Brown zaslal poznámky z tohoto setkání; přečíst si je můžete níže.
Celý článek na LWN.net
Čtenáři LWN si mohli přečíst reportáž z Linux Storage and Filesystem Summit (první den, druhý den), který se konal 8. a 9. srpna v Bostonu. Jonathan Corbet, autor výše zmíněných článků, se bohužel nemohl zúčastnit přednášek specifických pro úložiště, takže ty v článcích zmíněny nejsou. Naštěstí si James Bottomley pořídil podrobné poznámky, které nyní zveřejnil. Pod odkazem níže najdete iSCSI, správu SAN, thin provisioning, zkrácení [trim] a zahazování [discard], úložiště bez rotujících částí, vícecestná úložiště a další.
Celý článek na LWN.net
KVM Forum se konalo paralelně s konferencí LinuxCon 9. a 10. srpna. Slajdy ze všech prezentací, které se konaly, jsou k dispozici ke stažení ve formátu PDF.
napsal Jake Edge, 18. srpna 2010
Vývojáři vcelku pochopitelně chtějí, aby se jejich kód používal, ale zapínání nových věcí ve výchozí konfiguraci je často považováno za postup, který zachází až příliš daleko. Herbert Xu a další vývojáři subsystému crypto nedávno na tuto politiku narazili, když nastavili novou volbu, která řídí testování crypto ovladačů při bootu, na „ano“. Bezpochyby si mysleli, že je tato vlastnost důležitá – špatná kryptografie může vést k narušení systému nebo dat – ale Linux dlouhodobě dodržuje politiku, že nové vlastnosti by měly být ve výchozím nastavení vypnuté. Když David Howells narazil na problém způsobený chybou při nahrávání modulu cryptomgr, Linus rychle a ostře Herbertovi tuto politiku připomněl.
Přibližná příčina Davidových problémů je v tom, že modul cryptomgr vracel hodnotu, kvůli které se zdálo, že se nenahrál. To způsobilo na začátku bootování kaskádu problémů, protože se zavaděč modulů pokoušel zapsat chybové hlášení do /dev/console, který ještě neexistoval. Herbert zaslal patch, který problém opravil, ale David pomocí dělení půlením [bisect] ukázal na commit, který přidával možnost zakázat testování ovladačů a přitom testování ve výchozím nastavení zapínal.
Linus byl charakteristicky nevybíravý: Lidi si vždycky myslí, že jejich magický kód je tak důležitý. Na rovinu ti říkám, že absolutně není. Prostě to svinstvo úplně odstraň, prosím. Linuse nepotěšilo, že s výchozím nastavení na všech počítačích bude při každém bootu probíhat test. Herbert má ale obavy z poškození dat a potenciálně vadného hardwaru pro šifrování:
Linuse ale nepřesvědčil: Tu věc má otestovat vývojář. Tohle je absolutně nulová omluva pro to, aby byl každý uživatel nucen při každém bootu test znovu a znovu opakovat. Ostatní si ale tak jistí nebyli. Kyle Moffett poznamenal, že jeho osobně pokousaly nové ovladače, které neprošly testem a tak se místo nich použila softwarová implementace. Proto by byl rád, kdyby se provádělo více testování:
Linus ale tvrdí, že nutit každého uživatele platit náklady na testování při bootu, je příliš. Ovladače by měly být spolehlivé, nebo by neměly být v jádře. Pak pokračoval: A jestli máš obavu z alfa částic, měl bys při každém bootu testovat RAM. Ale nechtěj po mně, abych to dělal taky.
Herbert tedy zaslal patch, který testy ve výchozím nastavení vypíná, i když ten se ještě do hlavní řady nedostal. Vzhledem k Linusovým výrokům se tak nicméně pravděpodobně stane relativně brzy. Pokud distribuce s jeho názorem nebudou souhlasit, pak nejspíš ve svých jádrech tuto volbu zapnou.
napsal Jonathan Corbet, 16. srpna 2010
Začleňovací okno 2.6.36 se uzavřelo vydáním 2.6.36-rc1 15. srpna. Od shrnutí z minulého týdne bylo do hlavní řady začleněno přibližně 1000 sad změn; tento článek shrne významné změny počínaje změnami viditelnými pro uživatele:
Souborový systém Squashfs získal podporu pro souborové systémy komprimované pomocí LZO.
Souborový systém Ceph má nyní podporu pro doporučené zámky [advisory locking].
V subsystému pro multimediální karty (MMC) je nyní podpora pro operace výmazu [erase] a zkrácení [trim] (včetně „bezpečných“ variant). Bloková vrstva byla rozšířena o příznak REQ_SECURE a nový ioctl() příkaz BLKSECDISCARD, který tuto funkcionalitu podporuje.
Mezi změny viditelné pro vývojáře jádra patří:
Souborová operace ioctl() byla odstraněna, všichni uživatelé ve stromě byli konvertováni na verzi unlocked_ioctl(), která nezabírá velký jaderný zámek [big kernel lock]. Odstranění BKL se o další krok přiblížilo.
Téměř nepoužívaná funkce dma_is_consistent(), která měla zjišťovat, jestli lze na specifické oblasti paměti provést cache-koherentní DMA, byla odstraněna.
Kvůli snazšímu používání a výkonnosti bylo přepracováno API kfifo. Nějaké příklady, jak API používat, byly přidány do samples/kfifo.
Je zde nová sada funkcí, které se mají vyhnout souběhům s přístupem k parametrům modulů přes sysfs:
kparam_block_sysfs_read(name); kparam_unblock_sysfs_read(name); kparam_block_sysfs_write(name); kparam_unblock_sysfs_write(name);
name je jméno parametru, které se předává module_param() ve stejném souboru zdrojových kódů. Funkce jsou implementovány pomocí mutexu.
Byla přidána experimentální podpora pro multiplexované I2C sběrnice.
Během tohoto začleňovacího okna bylo začleněno nějakých 7700 změn. Tentokrát nebylo mnoho změn, kterým by byl vstup znemožněn. Největší nezačleněnou vlastností jsou nejspíš transparentní obrovské stránky [transparent hugepages], ale to lze s největší pravděpodobností přičíst chybějícímu požadavku na přetažení od správce.
Nyní začíná stabilizační období. Linus naznačil, že hodlá zopakovat svoji snahu nepřijímat po -rc1 jakékoliv změny, které zjevně nejsou důležité opravy; uvidíme, jak to bude v praxi.
napsal Jonathan Corbet, 18. srpna 2010
Co se stane, když se pokusíte do linuxového souborového systému vložit miliardu souborů? To by se dalo považovat za akademickou otázku; i ten nejvíc nadšený stahovač hudby by musel pracovat hodně dlouho, než by nasbíral tolik dat. Pro miliardu souborů by bylo potřeba rozbalit 30 000 kopií (čistého) jaderného stromu. I na současných desktopových systémech, které často vytvářejí spoustu malých souborů velice statečně, by bylo obtížné dočkat se miliardy. Jak ale říká Ric Wheeler, jedná se o problém, kterým bychom se měli zabývat nyní, jinak nebudeme schopni škálovat na úložné systémy zítřka. Jeho přednáška na LinuxConu používala pracovní zátěž s miliardou souborů jako způsob, jak prozkoumat škálovatelnost linuxového kódu pro úložiště.
První, nad čím se možná zamyslíme, když se před nás postaví představa práce s miliardou souborů, je, jak problém obejít. Místo toho rvát všechny tyto soubory na jediný souborový systém, proč je prostě nerozmístit na několik menších souborových systémů? Problém tohoto přístupu je v tom, že (1) omezuje schopnost jádra optimalizovat pohyb hlavičkami, což snižuje výkonnost, a (2) nutí vývojáře (nebo správce) potýkat se s problémy spojenými s distribucí souborů na jednotlivé souborové systémy. Věci se pak nevyhnutelně vychýlí z rovnováhy a vynutí přemisťování souborů.
Další možnost je místo souborového systému použít databázi. Souborové systémy jsou ale s operačními systémy spjaty od počátku a vývojáři i uživatelé jsou na ně zvyklí. Souborové systémy také lépe zvládají částečné selhání; u databází se naopak většinou jedná o záležitost všechno, nebo nic.
Kdyby někdo chtěl experimentovat se souborovým systémem s miliardou souborů, jak přijít k hardwaru, který to zvládne? Aktuálně je nejsnazší použít externí diskové pole – ta se dodávají s nonvolatilním cachováním a hierarchií úložných technologií. Poměrně často jsou rychlá při práci s proudy dat, ale náhodný přístup může být rychlý i pomalý podle toho, kde jsou uložena data, o která je zájem. Stojí od 20 000 dolarů výše.
Co se týče úložišť bez rotujících částí, Ric řekl jenom to, že 1 TB stále stojí dobrých 1000 dolarů, takže rotující disky tady s námi ještě nějaký rok pobudou.
Co když si budete chtít vytvořit 100TB pole sami? To zkusili v Red Hatu. Systém se skládal mimo jiné ze čtyř rozšiřujících polic, které obsahovaly 64 2TB disků. Stálo přes 30 000 dolarů a jak řekl Ric, obecně to byl špatný nápad. Jestli někdo chce velké úložné pole, nejlépe udělá, když půjde a koupí si ho.
Životní cyklus souborového systému podle Rica začíná operací mkfs. Pak je souborový systém zaplněn, různě se používá a občas je zapotřebí fsck. Někdy v budoucnu jsou soubory odstraněny. Ric sestavil sérii grafů, ve kterých ukazoval, jak se ext3, ext4, XFS a btrfs chovaly při každé této operaci na souborovém systému s milionem souborů. Výsledky se různily, ale konzistentní bylo, že ext4 se obecně chová lépe než ext3. Při vytváření souborového systému jsou ext3/4 mnohem pomalejší než ostatní, protože musí vytvořit statické tabulky inodů. Na druhou stranu nejhůře si při vytváření milionu souborů vedly ext3 a XFS. Všechny kromě ext3 si vedly přiměřeně dobře při fsck – i když u btrfs se objevuje prostor pro optimalizaci. Velký propadák při odstraňování milionu souborů předvedl XFS.
Grafy můžete vidět v Ricových slidech [PDF].
Jedna věc je do souborového systému vložit milion souborů, ale co miliarda? Ric tento experiment zkusil na ext4 a ,udělej si sám‘ poli popsaném výše. Jenom vytvoření souborového systému nebylo pro netrpělivé; trvalo to přibližně čtyři hodiny. Vytvoření miliardy souborů potom zabralo čtyři dny. Překvapivé je, že fsck na tomto souborovém systému trvalo jenom 2,5 hodiny – procházka parkem. Jinými slovy Linux miliardu souborů zvládne.
Z tohoto pokusu nicméně vyplynuly nějaké informace; z nich se dá určit, kde se objeví problémy. První z nich byl, že fsck na souborovém systému zabralo hodně paměti: Na 70TB souborovém systému s miliardou souborů bylo zapotřebí 10 GB RAM. Toto číslo se zvyšuje na 30 GB, když se použije XFS, takže věci mohou být i horší. Krátký závěr: Do malého serveru lze nacpat obrovské úložiště, ale nebudete na něm schopni spustit kontrolu. To je omezení, o kterém je dobré vědět.
Další lekce: XFS má i přes své přednosti potíže, když pracuje se zátěžemi, kde se intenzivně pracuje s metadaty. Na zlepšení v této oblasti se pracuje, ale ext3 se zatím v takových situacích chová lépe.
Podle Rica je spuštění ls na obrovském souborovém systému „špatný nápad“; iterace přes mnoho souborů může vygenerovat spoustu I/O aktivity. Když se snažíte podívat na tolik souborů, je potřeba vyhnout se řazení a volání stat() na každý soubor. Některé souborové systémy dokáží vrátit typ souboru se jménem ve volání readdir(), takže v mnoha situacích není nutné volat stat(); v tomto případě to může hodně pomoci.
Obecně je vypisování souborů pomalé; přinejlepším lze zvládnout několik tisíc souborů za sekundu. Zdá se to být hodně, ale pokud je cílem miliarda souborů, projít celý seznam trvá velmi dlouho. S tím spojený problém je zálohování/replikace. Obojí také zabere spoustu času a může to negativně ovlivnit výkon dalších věcí, které běží paralelně. To může být problém, protože i když záloha může trvat několik dní, je opravdu potřeba ji spustit na produkčním systému. V takových situacích by mohly výkonnost systému zachránit řídící skupiny [control groups] a řadiče I/O propustnosti.
A nakonec vývojáři aplikací musí mít na paměti, že procesy, které běží takhle dlouho, se nevyhnutelně budou dříve či později potýkat se selháními. Je tedy nutné navrhnout je s nějakou možností vytvořit kontrolní body a k těm se později vrátit. Také musíme vynechat opakované pokusy, když I/O operace selže – dlouhá čekání na opakování mohou způsobit, že se z pomalého procesu stane proces, který nelze ukončit.
V krátkosti: Jak se věci zvětšují, narazíme na problémy se škálovatelností. Na tom není nic nového, takové problémy jsme v minulosti vždy překonali a rozhodně bychom měli být schopni překonávat je i v budoucnu. Nicméně je vždycky lepší o těchto věcech mluvit dřív, než je jejich řešení urgentní, takže Ricova přednáška a podobné poskytují komunitě cennou službu.
napsal Jonathan Corbet, 18. srpna 2010
Jedno z viditelnějších rozhodnutí, ke kterému se dospělo na nedávném Linux Storage and Filesystem summit, bylo zbavit se podpory bariér v blokovém subsystému linuxového jádra. Toto rozhodnutí se líbilo, ale bylo trochu nepochopeno (dost možná nejvíce autorem článku). Nyní nová sada patchů od Tejuna Heo ukazuje, jak bude pravděpodobně v budoucnu řešeno řazení požadavků v blokové vrstvě.
Bloková vrstva musí být schopna změnit pořadí I/O operací s diskem, pokud se má zachovat výkonnost, kterou uživatelé od svých systémů očekávají. Na rotujících discích lze hodně získat minimalizací pohybu hlavičkami a tohoto cíle lze nejlépe dosáhnout tak, že se všechny požadavky v jedné oblasti zpracují naráz bez ohledu na pořadí, v jakém byly zadány. I u flashových zařízení lze získat tím, že se sousedící požadavky seskupí; obzvláště to platí v případě, že je možné menší požadavky sloučit do větších. Vysílání požadavků je normálně úkolem pro I/O plánovač; ten v blahé nevědomosti změní jejich pořadí, protože nemá tušení o rozhodnutích na vyšší úrovni, která tato požadavky vygenerovala.
Zde je potřeba vzpomenout, že ke změně pořadí dochází i v zařízení samotném; požadavky se ukládají do (potenciálně volatilní) cache a zápisy se provedou, když hardware usoudí, že je to vhodné. Tato změna pořadí je typicky pro operační systém neviditelná.
Problém samozřejmě spočívá v tom, že není vždy bezpečné libovolně měnit pořadí I/O požadavků. Klasickým příkladem je chování žurnálovacího souborového systému, který funguje přibližně takto:
Jestliže systém spadne před dokončením bodu 3, všechno v žurnálu se ztratí, ale integrita souborového systému zůstane neporušena. Jestliže systém spadne po bodě 3, ale před zapsáním změn do souborového systému, změny se přehrají při příštím připojení, takže jsou zachována metadata i integrita souborového systému. Díky žurnálování je tedy souborový systém relativně páduvzdorný.
Představme si ale, co by se mohlo stát, kdyby se změnilo pořadí požadavků. Jestliže je záznam o provedení zapsán předtím, než se všechny změny zapíší do žurnálu, přehraje se po pádu nekompletní žurnál, což souborový systém poškodí. Nebo pokud transakce uvolňuje nějaké bloky na disku, ty jsou následně znovu použity jinde a zapíší se do nich data předtím, než je provedena transakce, která je uvolnila, opět dojde při pádu k poškození. Souborový systém tedy zjevně musí být schopen vynutit řazení toho, jak jsou požadavky prováděny; jinak může být jeho snaha garantovat integritu za všech okolností k ničemu.
Několik let byly řešením požadavky na bariéru. Když souborový systém zadá požadavek blokové vrstvě, může ho označit jako bariéru, což znamená, že by bloková vrstva měla provést všechny požadavky zadané před bariérou dřív než požadavky zadané po ní. Bariéry tedy zajistí, že se operace na médiu projeví ve správném pořadí, přičemž bloková vrstva není příliš omezena a může měnit pořadí operací mezi bariérami.
V praxi mají ale bariéry nepříjemnou pověst zabijáků výkonnosti I/O; až do té míry, že jsou správci často v pokušení risknout to a vypnout je. Přestože značkované operace ve frontě [tagged queue operations] dostupné na současném hardwaru by měly bariéry implementovat dostatečně dobře, pokusy použít tyto vlastnosti obecně naráží na obtíže. Ve skutečném světě jsou tedy bariéry implementovány jednoduše tak, že se fronta I/O požadavků nechá vyprázdnit před zadáním bariérové operace; do toho se přihazují nějaké operace, které hardware donutí, aby data opravdu zapsal na trvalé úložiště. Vyprázdnění fronty zařízení brzdí a omezuje to paralelismus potřebný pro maximální výkon; není tedy překvapivé, že používání bariér může být problematické.
Ve svých diskuzích o tomto problému si vývojáři úložišť a souborových systémů uvědomili, že sémantika řazení poskytovaná blokovou vrstvou je mnohem silnější, než je zapotřebí. Souborové systémy potřebují zajistit, aby byly některé požadavky vykonány v daném pořadí a aby se specifické požadavky dostaly na fyzické médium předtím, než je možné zahájit jiné. Kromě toho souborové systémy nemusí zajímat řazení většiny ostatních požadavků, takže používání bariér omezuje blokovou vrstvu více, než je nutné. Obecně se došlo k závěru, že souborové systémy by se samy měly starat o řazení, protože k tomu mají nejlepší informace, a neházet problém na blokovou vrstvu.
Aby to implementoval, odstraňuje Tejunův patch operace tvrdých bariér; jakýkoliv souborový systém, který se pokusí je použít, dostane přes svou veškerou snahu veselou chybu EOPNOTSUPP. Souborový systém, který chce, aby operace proběhly ve specifickém pořadí, je prostě musí v daném pořadí zadat a čekat na dokončení tam, kde je potřeba. Bloková vrstva pak požadavky může řadit libovolně.
Co bloková vrstva udělat nemůže, je vyhnout se zodpovědnosti za to, aby se důležité požadavky dostaly na fyzické médium, když to souborový systém potřebuje. Takže zatímco bariéry mizí, nahradí je „požadavky na zápis“ [flush request]. Na dostatečně schopných zařízeních může mít požadavek na zápis dvě různé potřeby: (1) zápisová cache musí být před zahájením operace vyprázdněna a (2) data spojená s požadavkem na zápis musí být zapsána na fyzickém médiu před dokončením požadavku. Druhá část se obvykle nazývá požadavek na vynucení přístupu k jednotce [force unit access, FUA].
V takovém světě může žurnálovací souborový systém zadat všechny požadavky pro zápis do žurnálu vztahující se k dané transakci a pak počkat na jejich dokončení. V tu chvíli souborový systém ví, že se zápisy dostaly do zařízení, ale mohou být v interní cache. Zápis záznamu o provedení pak může následovat s nastavenými bity „flush“ a „FUA“; to zajistí, že se všechna data žurnálu dostanou na fyzické médium před záznamem o provedení a že záznam o provedení bude zapsán, když se požadavek dokončí. Mezitím se může pracovat na všech ostatních I/O operacích – pracujících s předchozími transakcemi nebo na těch, které běží bez transakcí – čímž nedojde ke zbrždění fronty, která charakterizuje bariérové operace implementované v současných jádrech.
Tato sada patchů byla přijata dobře, ale stále je potřeba dodělat nějakou práci obzvláště na konverzi souborových systémů tak, aby věci dělaly novým způsobem. Za tímto účelem zaslal sadu patchů Christoph Hellwig. Také bude potřeba spousta testování; vzhledem k tomu, jak závažné jsou důsledky selhání, by si jenom málokdo přál zavést v této oblasti nějaké chyby. Vývojový cyklus ale teprve začal, takže zbývá poměrně mnoho času věci setřást a rozchodit před otevřením začleňovacího okna 2.6.37.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.