Jaderné noviny – 28. 7. 2010: Potřebuje Linux znát čas vytvoření souboru?

Aktuální verze jádra: 2.6.35-rc6. Citáty týdne: Ted Ts'o, Russel King, Andrew Morton. Začíná plánování Jaderného summitu 2010. Časy vytvoření souboru. Zcache: Komprimovaná cache stránek.

Obsah

Aktuální verze jádra: 2.6.35-rc6

Současné vývojové jádro je stále 2.6.35-rc6 vydané 22. července. Linus říká:

Vlastně si myslím/doufám, že to bude poslední -rc. Věci poměrně utichly a i když má tento -rc více commitů, než měl -rc5, není to o moc víc a podle mě to nevypadá děsivě. Takže se mi nezdá, že by mělo smysl vydání více protahovat, pokud nenajdeme něco, kvůli čemu by to bylo zapotřebí.

Tato verze obsahuje většinou opravy, ale také přejmenování subsystému logického bloku paměti [logical memory block, LMB] na „memblock“. Zkrácený changelog vizte v oznámení, všechny detaily vizte v kompletním changelogu.

Citáty týdne: Ted Ts'o, Russel King, Andrew Morton

Jeden z hlavních důvodů, proč jsem před deseti lety založil jaderný summit, je, že jsem zjistil, že lidé lépe spolupracují, když měli možnost setkat se tváří v tvář. Když někoho znáte jenom přes e-mail, je o moc jednoduší s ním vést flamewary. Když jste ale někoho potkali, pojedli jste spolu a pili pivo, je jednodušší spolupracovat s ním jako s kolegou vývojářem. I když se komunita vývojářů linuxového jádra od března 2001 významně rozrostla, tento princip stále platí.

To je jeden z důvodů, proč jsem před osmi lety napsal dokument o bootování Linuxu na ARMu, kde jsem specifikoval minimum informací, které zavaděč musí jádru předat, aby mohlo nabootovat. K ničemu – pokud jde o mě, psaní dokumentace je naprosté a totální plýtvání časem. Prostě je ignorována.

Takže teď se nenamáhám s vůbec žádnou dokumentací.

Moje instinktivní reakce na takovouhle záležitost je „s děsem zdrhnout“. Podporuje to jaderné vývojáře v tom, aby se chovali jako vývojáři v uživatelském prostoru a aby předpokládali, že kód níže dokáže provést heroické a nesmrtelné činy. Nedokáže. Tohle je jádro a jádro je drsné a nepřátelské místo a volající by měli být defenzivní v tom, aby se hodně snažili minimalizovat tlak, který vyvinou na jiné systémy.

Začíná plánování Jaderného summitu 2010

Jaderný summit [Kernel summit] 2010 se odehraje v Cambridge ve státě Massachusetts 1. a 2. listopadu, těsně před Konferencí linuxových instalatérů [Linux Plumbers Conference]. Plánování tohoto summitu začalo a výbor pro program hledá nápady, co by mělo být diskutováno a kdo by se měl zúčastnit. Jaderný summit organizuje výbor pro program, ale stejně tak by se snadno dalo říci, že jej organizuje celá komunita vývojářů. Což znamená, že jeho cílem je zajistit, aby vývoj linuxového jádra fungoval plynuleji. To, o čem mluvíme, je určeno tím, na čem se zrovna ve vývojové komunitě pracuje ve velkém měřítku. Proto potřebujeme vaši pomoc.

Časy vytvoření souboru

Linuxové systémy, stejně jako unixy, které přišly před nimi, pro každý soubor udržují tři časové značky. Sémantika těchto značek je ale pro uživatele často překvapující a značky neposkytují ty informace, které by uživatel chtěl znát. Možný přírůstek do jádra v podobě nového systémového volání dává jaderným vývojářům příležitost udělat v této oblasti nějaké změny, ale ještě nedošlo ke konsenzu o tom, jak to udělat.

Unixové časové značky, které kdysi dávno posvětil POSIX, se nazývají „atime“, „ctime“ a „mtime“. Značka atime má zaznamenávat poslední čas, kdy se k souboru přistupovalo. Tato informace ale téměř nikdy není používána a udržovat ji může být poměrně drahé; Ingo Molnár kdysi atime nazval v celé historii Unixu pravděpodobně nejhloupější nápad při jeho návrhu. Atime je tedy často na současných systémech zakazováno nebo alespoň omezeno na nepříliš často aktualizující režim „relatime“. Mtime naopak v podstatě dává smysl; říká uživateli, kdy byl soubor naposledy změněn. Změna souboru vyžaduje zápis tak jako tak, takže aktualizace tohoto času je často zadarmo a informace je často užitečná.

Tím zbývá ctime, což je trochu podivná potvora. Uživatelé, kteří se nepodívají dostatečně důkladně, rádi interpretují ctime jako čas vytvoření [creation time], ale to tam uloženo není; ctime se aktualizuje, když se mění metadata souboru. Hlavním uživatelem této informace je podle všeho prastará utilita dump, která si ráda zjišťuje, že se změnila metadata souboru (a tedy že je zapotřebí uložit je v inkrementální záloze), ale data ne, takže je není potřeba ukládat znova. Počet uživatelů dump během let rozhodně poklesl až do té míry, že největší roli, kterou ctime hraje dneska, je pravděpodobně matení uživatelů, kteří by chtěli znát čas vytvoření souboru.

Kde tedy uživatelé najdou čas vytvoření? Nikde: Linuxové systémy tento čas neukládají a neposkytují žádné rozhraní, kterým by se k němu aplikace mohly dostat.

Tato situace by se ale mohla změnit. Některé novější souborové systémy (například Btrfs a ext4) byly navrženy s prostorem, kam uložit čas vytvoření souboru. Jiné operační systémy tuto informaci poskytují také a některé protokoly pro síťové souborové systémy očekávají, že k této informaci budou mít přístup. Bylo by tedy hezké, kdyby Linux čas vytvoření podporoval správně; navrhované přidání systémového volání xstat() by mohla být vhodná chvíle pro tuto změnu.

Současná implementace xstat() dokonce do struct xstat; přidává pole st_btime; „b“ jako birth (narození), což je konvence, kterou vytvořili v táboře BSD. Tento příspěvek nicméně vyvolal poměrně slušnou diskuzi o pojmenování a sémantice.

O záležitosti s pojmenováním by si jeden myslel, že bude relativně přímočará. Někdo však upozornil, že se v jádře používají i jiná jména. JFS a Btrfs z nějakého důvodu používají „otime“, zatímco ext4 používá „crtime“. A jak se ukázalo, BSD nepoužívá „btime“, ale „birthtime“. Tato diskuze způsobila, že Linus vykřikl:

Wow. A tohle všechno mě jenom přesvědčuje o tom, že bychom nic takového dělat neměli, protože je to zjevně totálně k ničemu a lidi se nedokáží shodnout ani na jméně.

Poté se však Linus podíval trochu více zblízka na problém, který viděl v tom, že je zapotřebí poskytnout čas vytvoření souboru ve stylu Windows, který by mohla použít Samba. Ukazuje se, že Windows umožňuje modifikovat čas vytvoření, takže ho Linus považuje za variaci unixového ctime. To vedlo k návrhu změnit sémantiku ctime, aby to lépe vyhovovalo příkladu s Windows. Koneckonců téměř nikdo stejně ctime nepoužívá a změna, která by zajistila, že se ctime bude tvářit jako čas vytvoření ve Windows, by byla triviální. Toto chování by šlo specifikovat buď jako příznak procesu, nebo jako připojovací volba; pak by nebylo potřeba přidávat nová pole.

Tento nápad ale nebyl příliš populární; Jeremy Allison řekl, že by to vedlo k ještě hroznějším zmatkům. Pokud by ctime mohlo v různých situacích znamenat různé věci, ještě méně lidí by ho skutečně pochopilo a nástroje jako Samba by se na sémantiku stejně nemohly spoléhat. Jeremy by byl raději, kdyby se prostě přidalo nové pole; zdá se, že asi dojde k tomu.

Je tu však ještě jedna zajímavá otázka: Mělo by jádro povolit změnu času vytvoření? Windows změnu povolují a některé aplikace na této vlastnosti zjevně závisí. Windows také zjevně obsahují hack, který zajišťuje, že když je soubor smazán a na jeho místo nahrán jiný se stejným jménem, použije se starý čas vytvoření. BSD systémy naopak čas vytvoření změnit neumožňují. Když Samba poskytuje soubory z BSD, ukládá „windowsovský čas vytvoření“ [windows creation time] v rozšířeném atributu, takže lze poskytnout obvyklou sémantiku.

Když bude začleněn současný patch xstat(), Linux ve výchozím nastavení nepovolí změny času vytvoření – nebude žádné systémové volání, které by tuto změnu mohlo provést. Poskytnutí této možnosti by znamenalo rozšířit funkci utimes(), která může přijmout dodatečné informace. Umožnit změnu času by znamenalo menší spolehlivost, ale na druhou stranu by to bylo užitečné pro zálohovací programy, které by tak mohly obnovit původní čas vytvoření souboru. K této diskuzi však ještě nedošlo; čas vytvoření prozatím změnit nelze.

Zcache: Komprimovaná cache stránek

Loni Nitin Gupta tlačil do hlavní řady patch compcache, který implementoval swapovací zařízení ukládající komprimované stránky do hlavní paměti. Postupem času se z compcache stal ramzswap, který se dostal do stromu staging. Není jasné, jestli se ramzswap někdy propracuje do hlavní řady, Nitin se tedy znovu snaží s dílem, které nazval zcache. Zcache však jasnou cestu do hlavní řady aktuálně postrádá také.

Jako její předchůdci i zcache žije proto, aby ukládala komprimované kopie stránek do paměti. Už nevypadá jako swapovací zařízení, nyní je to poskytovatel úložiště pro framework cleancache. Cleancache používá sadu háčků v kódu cache stránek a souborového systému; když je z cache vytěsněna stránka, předává se Cleancache, která může (ale nemusí) někam uložit kopii. Když je daná stránka znovu zapotřebí, Cleancache dostane šanci ji obnovit předtím, než se ji jádro pokusí načíst z disku. Jestliže Cleancache (a její úložiště) bude schopna rychle ukládat a obnovovat stránky, existuje tu dobrý potenciál pro zlepšení výkonnosti systému.

Zcache používá LZO, pomocí kterého komprimuje stránky, jež jí předává Cleancache; ukládají se pouze stránky, které se zkomprimují na méně než polovinu původní velikosti. Také je zde zvláštní test na stránky obsahující jenom nuly; ty se komprimují obzvlášť dobře, protože nepotřebují vůbec žádné místo na úložišti. Zatím však neexistuje žádná snaha sjednotit stránky s duplicitním obsahem (jak to dělá KSM).

Při používání mechanismu jako zcache se samozřejmě mění něco za něco: V tomto případě narůstá spotřeba paměti a času CPU. Ohledně paměti Nitin říká:

I když komprese omezuje I/O disku, omezuje také místo dostupné pro normální (nekomprimovanou) cache stránek. To může vést k častějšímu znovuzískávání z cache stránek a tím větší režii CPU. Je tedy důležité udržovat dobrý podíl nalezených stránek, jinak zvýšená režie CPU vynuluje všechny ostatní přínosy. To vyžaduje adaptivní změnu velikosti (komprimované) cache a politiky nahrazování stránek, které budou schopny udržovat optimální velikost cache a rychle znovuzískávat nevyužívané komprimované kousky. To je ještě potřeba udělat.

Současný patch umožňuje správci systému manuálně nastavit velikost oblasti pro zcache, což je začátek. Nebude však asi moc adminů, kteří by chtěli pozorovat počet stránek, které byly nalezeny v cache, a podle toho upravovat nízkoúrovňové parametry správy paměti, aby bylo chování nepřetržitě optimální. Zcache si tedy téměř s určitostí bude muset vypěstovat nějaké samoladění, než se bude moci dostat do hlavní řady.

Další věc, kterou je nutné obětovat, je čas CPU: Komprimovat a dekomprimovat stránky paměti zabírá čas. Tato cena se zvyšuje u všech stránek, které se nepodaří zkomprimovat na méně než 50 % původní velikosti – čas strávený jejich komprimováním je naprostým plýtváním. Jak ale upozorňuje Nitin: S tím, jak jsou čím dál běžnější vícejádra, by měly výhody pocházející z omezení I/O snadno převážit zvýšenou zátěž CPU. Lidé se často ptají, co budeme dělat se zvyšujícím se počtem jader na současných procesorech; zcache je možná součást odpovědi.

Ještě ale zbývá vyřešit jednu záležitost: Zcache závisí na Cleancache, která v současnosti není v hlavní řadě jádra. Proti začlenění Cleancache existuje opozice, hlavně kvůli patchi, který mění jednotlivé souborové systémy a který je považován za příliš rušivý. Také není jisté, že každý chápe hodnotu Cleancache, přestože ji SUSE již nějakou dobu dodává. Dokud nebude osud Cleancache rozhodnut, přídavné patche jako zcache budou čekat mimo hlavní řadu.