Jaderné noviny – 3. 4. 2014: Diskové bloky větší než 4K

Aktuální verze jádra: 3.14. Citáty týdne: Linus Torvalds, Chris Mason, Josh Boyer. Novinky o revoke() a ještě více. Disky s velkými sektory.

Obsah

Aktuální verze jádra: 3.14

Citáty týdne: Linus Torvalds, Chris Mason, Josh Boyer

Ano, tohle mě osobně neskutečně vytáčí. Naše konfigurační prostředí je tou naprosto nejhorší částí jádra a není to kvůli tomu, že by Kconfig byl složitý jazyk. Je to kvůli tomu, že odrazuje lidi od sestavování vlastního jádra a testování, jelikož je nesmírně složité odpovídat na naše otázky a vypadá to, že vyzýváme lidi k zapínání funkcí, které jsou zbytečné a jen dělají sestavování pomalejším a obtížnějším.

Během sumitu, co byl minulý týden, Jon Corbet navrhl, abychom ke zlepšení procesu revidování jaderných patchů využili sílu sociálních médií.

Přišlo nám to jako super nápad a zkoušíme novou skupinu na Facebooku, kde se probírají a revidují patche. Tato nová skupina nám významným způsobem zlepšila vývojový proces, a to včetně:

Schvalování patche nebo komentáře na jeden klik.
Komentářů s možností obrázků a videa.
Kdo viděl vaše patche a komentáře.
Prohledávatelného indexu předchozích příspěvků.
Silné komunity bez anonymních flamewarů.

Aby bylo možné zachytit debatu skupiny při konečném zaslání patche, navrhujeme přidání tagu Líbilo-se: do commitů, které prošly skupinovým revidováním.

Pro ty z vás, kteří nepoužívají Facebook, připravujeme i účet na Twitteru, který bude zveřejňovat patche po 140 znacích. Při revidování se bude jen hodit, když budou patche automaticky rozdělené do zvládnutelných 140znakových kousků.

Novinky o revoke() a ještě více

Na Linuxovém sumitu o úložištích, systémech souborů a správě paměti 2014 Al Viro zpravil přítomné o současném stavu revoke(). revoke() má udělat close() na stávajících popisovačích pro danou cestu, aby si proces mohl být jistý, že má možnost daný soubor nebo zařízení používat výhradně. Viro také probíral práci, kterou odvedl na sjednocení různých variant systémových volání read() a write().

Viro svou řeč zahájil slovy, že revoke() bude její méně zajímavou částí. Vcelku se to podle něj přibližuje dokončení. Před rokem jsme se podívali na starší verzi jeho práce. Soubory mohou být označeny jako revokovatelné při volání open(). Pokud jsou takto označené, pak bude čítač sledovat používání funkcí z file_operations. V moment zavolání revoke() se počká na dokončení všech operací ve file_operations a zajistí se, že další nejsou spuštěny.

V procfs a sysfs jsou místa, kde je něco podobného naprogramováno napřímo. Podle Vira by toto mohlo být po začlenění podpory pro revoke() odstraněno. Jednou z důležitých věcí je zajistit, aby běžné používání nebylo kvůli revoke() zpomaleno, jelikož většina souborů nebude revokovatelná. Najde se ještě několik oblastí, na kterých je potřeba pracovat, včetně poll(), které představuje jisté komplikace, a mmap(), které bylo pro revoke() vždy problematické.

Lehce mimo téma Viro poznamenal, že se v kódu najde hodně míst, která jsou „naprosto rozbitá“. Pokud je například otevřen soubor v debugfs a příslušný kód odstraní soubor z adresáře debugfs, pak jakákoliv operace čtení nebo zápisu nad popisovačem způsobí oops jádra. Dynamické debugfs je naprosto rozbité, řekl Viro. Doufá, že kód revoke() bude po několika cyklech v rozumném stavu – „blíží se to k tomu“. Dynamické debugfs bude jedním z prvních uživatelů.

Viro se pak přesunul k tématu sjednocení obyčejných volání read() a write() s variantami readv()/writew() a také s splice_read() a splice_write(). Běžné a vektorové varianty (readv()/writew()) už byly povětšinou zkombinovány. Není to „pěkné“, ale je to únosné. Varianty splice jsou dost „hrozné“.

V ideálním případě by měl kód všech variant vypadat stejně, a to až do místa, kde dochází ke konečnému předání. Každá z variant má ale vlastní pohled na data; varianty splice pracují s daty ve stránkách, což nejde moc dohromady s iovec používanými u dalších dvou variant (ve většině implementací se obyčejné read() a write() překládá do iovec o délce jedna). Vytvoření nové datové struktury, ve které mohou být uživatelská i jaderná pole iovec spolu se struct page pro varianty splice, by mohlo podle Vira být přijatelné.

Vedlejším produktem jeho práce v této oblasti je přidání iov_iter. Operace iov_shorten() se snaží přepočítat počet síťových segmentů, které spadají do dané oblasti iovec, výsledkem je ale to, že je při krátkých čteních nebo zápisech iovec upraveno. Ještě horší je to, že úprava iovec je závislá na protokolu, což uživatelům komplikuje práci. Pravdou je, že někdo z týmu CIFS řekl, že dělá kopii každého iovec před předáním, protože neví, co se mu vrátí.

Je „naprosto špatné“, aby to bylo závislé na protokolu, řekl Viro. Zbavoval se volání iov_shorten(), stejně tak i dalších míst, která zkracují pole iovec. To by mohlo umožnit úplné odstranění sendpage(); protokoly, které chtějí být chytrými, si mohou připravit iov_iter, řekl.

Disky s velkými sektory

Podpora disků o velkých sektorech (nad 4 KB) byla námětem krátké řeči Rica Wheelera. Podpora disků s 4K sektory se objevila teprve v minulých letech, ale u 4K sektorů se nekončí.

Wheeler se zeptal výrobců disků, zda zvolili 4K jako velikost sektorů dobrovolně, nebo jen proto, že šlo o největší velikost podporovanou operačními systémy. I když na otázku nikdo přímo neodpověděl, bylo jasné, že by se výrobcům v této oblasti zamlouvala větší flexibilita. I když třeba nemají zájem o 256M sektory (jak ze srandy navrhl Martin Petersen), úložná pole interně používají 64K a 128K sektory už nějakou dobu.

Dave Chinner se ptal, jaké vrstvy by bylo nutné změnit, aby byly podporovány větší velikosti sektorů, a označil kód systémů souborů a kód pro práci s oddíly za pravděpodobné potížisty. Také řekl, že možnost dělat I/O o velikosti stránky je základním předpokladem napříč celým kódem cache stránek. Jan Kara zmínil „reclaim“ jako další místo, kde tento předpoklad je. Stránky na Linuxu mají obvykle velikost 4K.

Jedním způsobem, jak to vyřešit, by bylo pomocí kousků bloků [chunks], jako to udělal IRIX se svou chunk cache. Šlo o vícestránkovou cache bufferů, která byla vytvořena právě kvůli ošetření těchto případů. Není si ale jistý, zda to opravdu chceme udělat takhle. Petersen zmínil další komerční Unix používající podobné schéma.

Mohla by tam být i vrstva umožňující čtení a zápis o velikostech menších než sektor. Pak by ale musela provádět cykly přečti-uprav-zapiš pro zápis menších kousků, což by bylo pomalé, řekl Chinner.

Výrobci ale na podporu větších sektorů netlačí hned. Je proto čas vyřešit problémy správným způsobem. Ted Ts'o řekl, že prvním krokem je podporovat sektory větší než velikost stránky.