Jaderné noviny – 21. 6. 2012: Za flash úložiště výkonnější

9. 7. 2012 | Luboš Doležel

Články - Jaderné noviny – 21. 6. 2012: Za flash úložiště výkonnější  

Aktuální verze jádra: 3.5-rc3. Citáty týdne: Greg Kroah-Hartman, H. Peter Anvin. Brown: zákeřná chyba v md/raid. Podpora kontextů blokového I/O.

Obsah

• Aktuální verze jádra: 3.5-rc3
• Citáty týdne: Greg Kroah-Hartman, H. Peter Anvin
• Brown: zákeřná chyba v md/raid
• Podpora kontextů blokového I/O

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

Aktuální verze jádra je 3.5-rc3 vydaná 16. června. Týden začal zvolna s pár drobnými přetaženími, lidé se mi zjevně snaží během mých cest usnadnit život – díky. Ale pak se to nějak pokazilo a řekl bych, že víc než polovina žádostí o přetažení přišla během posledních dvou dnů a byly i větší. No jo... Jde hlavně o opravy, ale najdete tam i nový síťový ovladač pro systémy Tile-Gx.

Stabilní aktualizace: verze 3.0.35 a 3.4.3 vyšly 17. června; 3.2.21 vyšlo 19. června. Všechny verze obsahují pravidelnou dávku oprav.

Aktualizace 3.0.36 a 3.4.4 se aktuálně revidují; jejich vydání lze očekávat 22. června nebo později.

Citáty týdne: Greg Kroah-Hartman, H. Peter Anvin

Je mi to líto, konstruktivně to vždycky nejde, ale vynasnažím se. Také se zkusím vyhnout narážkám na tvou kočku, ale jestli mě budeš dráždit, tak se nedá nic vyloučit.

-- Greg Kroah-Hartman

Háčky (hooks) a notifikátory jsou programováním ve stylu „COME FROM“ a je těžké o nich diskutovat. Jediný způsob, jakým se dá toto potlačit, je mít u háčku a notifikátoru přesnou sémantiku – prekondice, postkondice a další invarianty – pečlivě zdokumentovanou. Ze zkušeností vím, že v reálu je četnost takového dokumentování někde mezi výjimečně a nikdy.

-- H. Peter Anvin

Brown: zákeřná chyba v md/raid

Neil Brown napsal blogový zápisek o pěkně zákeřné chybě v RAIDu na některých verzích Linuxu. Chyba se projeví jen při vypnutí/restartu stroje. Dokud stroj běží, tak se vůbec nic nestane. Takže si chyby všimnete, jen když stroj opětovně spustíte. Následkem chyby je odstranění důležitých informací z metadat uložených na discích. Kromě dalších informací jde hlavně o level, chunksize, počet zařízení, data_offset a roli každého ze zařízení. To znamená, že pokud tyto podrobnosti víte, tak obnova bude snadná, ale když ne, tak to bude těžší. Proto ten příkaz „mdadm -E“ navrhovaný dříve.

Podpora kontextů blokového I/O

Paměťová úložná zařízení včetně Flash pamětí jsou v podstatě jen zařízení s náhodným přístupem s určitými sobě vlastními omezeními. Kdyby vývojáři Linuxu měli přímý přístup k zařízení, jistě by časem stvořili ovladače, které by poskytovaly optimální výkon a životnost zařízení. V reálném světě jsou ale tato zařízení ukryta za svými vlastními proprietárními operačními systémy a dalším softwarem; většina skutečné (komerční) hodnoty se zdá být v softwaru bundolovaném kdesi vevnitř. Následkem toho se jádro musí snažit přesvědčit firmware zařízení k tomu, aby odváděl dobrou práci. Jak plynul čas, tak výrobci úložišť přidali různé mechanismy, pomocí kterých může operační systém předávat zařízení všelijaké tipy; mechanismus „trim“ nebo „discard“ je jedním z nich. Novější zařízení eMMC a unified flash storage (UFS) mají nový „tip“ v podobě „kontextů“; pro podporu této funkce už existují patche, ale zjevně vyvolaly více otázek než odpovědí.

Dokumenty standardu, které by popisovaly kontexty, se nezdají být běžně dostupné – nebo alespoň nalezitelné. Z toho, co váš redaktor byl schopen odvodit, jsou tyto „kontexty“ malým číslem přidaným do I/O požadavků, které mají zařízení pomoci optimalizovat spouštění těchto požadavků. Smyslem je odlišit různé typy I/O, respektive od sebe odlišit velké, sekvenční operace od malých, náhodných. I/O lze umístit do kontextu „velké jednotky“, kde operační systém slibuje, že bude odesílat velké požadavky a nebude se snad ani pokoušet data znovu číst, než bude kontext uzavřen.

Saugata Das nedávno zaslal malý patch, který dodává podporu kontextů do souborového systému ext4 a blokového ovladače MMC. Na nižší úrovni jsou čísla kontextů svázána s požadavky blokového I/O uložením čísla v nově vytvořených polích bi_context (v struct bio) a context (ve struct request). O nastavení těchto polí se stará VFS, ale se správnými čísly kontextu musí nakonec přijít samy souborové systémy. Přidává se nová operace (nazvaná get_context()), pomocí které se VFS může dotázat souborového systému na číslo kontextu pro konkrétní požadavek. Bloková vrstva byla upravena tak, aby nedocházelo ke slučování požadavků blokového I/O, pokud byl těmto požadavkům přidělen jiný kontext.

O změnách na nižší úrovni se moc nediskutovalo, zjevně vývojářům dávají smysl. Více se řešily změny na úrovni souborového systému. Saugatův patch upravuje pouze ext4; tyto změny způsobují, že ext4 používá číslo inode souboru jako číslo kontextu. Všechny I/O požadavky na jednom souboru tedy budou přiřazeny do stejného kontextu a požadavky na různých souborech půjdou zase do různých kontextů (ale má to svá omezení – eMMC například podporuje jen 15 kontextů, takže mnoho čísel inode bude na nižší úrovni mapováno na stejný kontext). Otázkou tedy bylo: je používání čísla inode tím správným pravidlem? Hledat odpověď znamená vyřešit dvě nezávislé otázky: 1) co mechanismus kontextů vlastně dělá a 2) jak mohou systémy souborů na Linuxu poskytnout úložným zařízením ty nejlepší informace o kontextu?

Arnd Bergmann (který strávil snahou pochopit detaily fungování flash úložišť spoustu času) poznamenal, že standard je co do popisu fungování kontextů úmyslně nekonkrétní; autoři chtěli vytvořit něco, co přežije současné technologie. Dále řekl:

Přesto si ale myslím, že je docela jasné, co měli autoři specifikace na mysli a při současných flash technologiích je jen jediná možná rozumná implementace: Získáváte něco jako strukturovaný souborový systém s 15 kontexty, kde každý kontext zapisuje do právě jednoho erase bloku v daný okamžik.

Dopadem takové implementace by bylo shromažďování dat zapsaných v jednom kontextu do jediného erase bloku (nebo skupiny erase bloků). To znamená, že máme několik způsobů, jak použít kontexty k optimalizaci I/O výkonu.

Například bychom se mohli snažit shromažďovat data se stejnou očekávanou životností, takže jakmile je část erase bloku odstraněna, budou odstraněna i všechna data v tomto erase bloku. Používání čísla inode v číslu kontextu by takový efekt mít mohlo; odstranění souboru spojeného s daným inode povede k odstranění všech jeho bloků současně. Takže dokud nebude soubor vystaven náhodným zápisům (jako by například mohl být databázový soubor), používání kontextů tímto způsobem by mohlo snížit objem garbage collection a cyklů read-modify-write při mazání souborů.

Jiným užitečným přístupem by bylo používání kontextů k oddělení velkých souborů s dlouhou životností od těch, které ji mají kratší. Velké soubory by byly na médiu dobře umístěny a méně stálá data by byla soustředěna do menšího množství erase bloků. V tomto případě by používání čísla inode pro označní kontextu nemuselo vždy fungovat dobře. Velké soubory by byly dobře odděleny, ale stejně tak by mohly být odděleny i ty malé, což nemusí být zrovna to, co chceme: pokud by se několik malých souborů vešlo do jediného erase bloku, výkon by se mohl zlepšit, pokud by všechny tyto byly zapisovány do stejného kontextu. V tomto případě by se mohla hodit odlišná pravidla.

Ale jak by tato pravidla měla vypadat? Arnd navrhl, že by mohlo lépe posloužit číslo inode nadřazeného adresáře. Různí diskutéři navrhli, že by se mohlo použít i číslo s ID procesu, který soubor zapisuje, i když by tu vznikly jisté komplikace, pokud by do souboru zapisovalo více procesů současně. Ted Ts'o navrhl, že shlukování souborů zapsaných stejným procesem během krátké chvíle by mohlo dávat dobré výsledky. Podle něj by také mohlo být užitečné dívat se na velikost souboru vzhledem k velikosti erase bloku zařízení; soubory mnohem menší než erase blok by mohly jít do stejného kontextu, zatímco ty větší by dostaly svůj vlastní.

S tím souvisel další nápad, opět od Teda, tedy sledovat očekávané chování I/O. Pokud je existující soubor otevřen pro zápis, tak je docela velká šance, že výsledkem bude náhodné I/O. U souborů otevřených s O_CREAT je zase větší šance, že přístup bude sekvenční; oddělení těchto dvou typů souborů do různých kontextů by mohlo dávat lepší výsledky. Takto by se mohly používat i některé příznaky v posix_fadvise(). Bez pochyby existují i další možnosti. Vybrání konkrétního řešení se musí dělat opatrně; špatná volba by mohla snadno snížit výkon a životnost namísto prodloužení.

Hledání řešení určitě chvíli potrvá, tím spíš, když je zatím problém na zařízení s podporou kontextů narazit. Podle Arnda představuje brzké zahrnutí podpory do ext4 jistou příležitost:

Kdybychom v ext4 měli podporu kontextů, tak by bylo pravděpodobnější, že optimalizace firmwaru budou založeny na chování ext4 namísto na chování jiného souborového systému nebo operačního systému. Z rozhovorů s výrobci zařízení emmc vyplynulo, že ext4 je na seznamu souborových systémů, pro které se má optimalizovat, hodně vysoko, protože všichni cílí na zařízení s Androidem.

A ext4 je zjevně preferovanou volbou pro současné androidí systémy. Tudíž se dá uvažovat o tom, že by implementace v ext4 mohla ovlivňovat chování hardwaru, stejně jako je tomu tak v případě Windows a hardwaru pro desktopy.

Vzhledem k tomu, že patche jsou docela malé a pravidla je možné v budoucnu měnit, aniž by to mělo dopad na kompatibilitu s uživatelským prostorem, je vysoká šance, že něco bude začleněno do jádra už ve vývojovém cyklu 3.6. Pak už to bude jen otázkou toho, co výrobci hardwaru doopravdy udělají, a podle toho se zařídit. Pokud budeme mít štěstí, tak výsledkem budou zařízení, která vydrží déle a budou mít lepší výkon.

Diskuse k tomuto článku

[Nikola Ciprich]

myslim ze tam nema byt dm/raid ale md/raid ktereho se problem tykal.

[Luboš Doležel (Doli)]

Díky, opraveno.