Jaderné noviny – 22. 8. 2013: Další optimalizace časových razítek

9. 9. 2013 | Luboš Doležel

Články - Jaderné noviny – 22. 8. 2013: Další optimalizace časových razítek  

Aktuální verze jádra: 3.11-rc6. Vše o novém návrhu řídících skupin. Samsung vydal zdrojový kód pro exFAT. Oddalování aktualizací mtime a ctime.

Obsah

• Aktuální verze jádra: 3.11-rc6
• Vše o novém návrhu řídících skupin
• Samsung vydal zdrojový kód pro exFAT
• Oddalování aktualizací mtime a ctime

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

Aktuální vývojová verze jádra je 3.11-rc6 vydaná 18. srpna. Linus k ní řekl: Byl to vcelku poklidný týden a rc se rozhodně zmenšují. A to mě těší. Konec vývojového cyklu 3.11 se blíží.

Stabilní aktualizace: Greg Kroah-Hartman makal jako šroubek, 14. srpna vydal verze 3.10.7, 3.4.58 a 3.0.91 a 20. srpna vydal verze 3.10.8, 3.4.59 a 3.0.92. O pár hodin později vydal verze 3.10.9 a 3.0.93 s jediným patchem navíc, co opravoval problémy ve verzích 3.10.8 a 3.0.92. Aby předešel podobným problémům v budoucnu, tak aktuálně zvažuje úpravy v tom. jak bude vybírat patche pro stabilní vydání. Ve zkratce: až na urgentní opravy budou všechny patche čekat asi týden, než budou zařazeny do stabilního vydání.

Minulý týden ještě vyšly další aktualizace, a to 3.6.11.7 (19. srpna), 3.5.7.19 (20. srpna) a 3.5.7.20 (21. srpna).

Vše o novém návrhu řídících skupin

Na Linux.com vyšel pohled na řídící skupiny (cgroups) zaměřený na problémy v aktuální implementaci a to, jak se budou opravovat. Článek řeší také to, jak systemd chystá podporu jednotné hierarchie řadičů namísto vícero hierarchií, co se používají teď. „To je částečně kvůli tomu, že cgroups přidávají dodatečnou složitost a režii do existujících subsystémů a přilepení načeho navrch je často cestou nejmenšího odporu,“ říká Tejun Heo, správce subsystému řídících skupin. "Spolu se skutečností, že cgroups prozkoumávají nové oblasti bez zavedených příkladů, které by bylo možné následovat, to vedlo k pochybným rozhodnutím v návrhu a relativně velké nekonzistenci.

Samsung vydal zdrojový kód pro exFAT

Software Freedom Conservancy oznámilo, že pomohlo tomu, aby Samsung vydal svou implementaci systému souborů extFAT pod GPL. Kód byl dříve neoficiálně vydán poté, co jeho kopie unikla ze Samsungu. Hlavním cílem organizace vždy bylo a je pomáhat a radit s cílem dosáhnout nejlepšího řešení co se dodržování GPL týče. Conservancy je potěšeno, že bylo dosaženo správného výsledku: legitimního, úplného vydání kódu ze strany Samsungu, a to pod licencí Linuxu, tedy GPL verze 2.

Oddalování aktualizací mtime a ctime

V roce 2007 si vývojáři jádra uvědomili, že udržování času posledního přístupu k souboru („atime“) představuje nemalý výkonnostní problém. Aktualizace atime převedly všechny operace čtení na zápis, což značně zpomalovalo I/O subsystém. V reakci na to přibyla volba pro připojování „relatime“, která snížila četnost aktualizací atime na minimum bez rizika rozbití aplikací. Od té doby se o výkonnostních problémech spojených s aktualizací časových razítek moc neuvažovalo.

Až doteď. Unixové systémy pro každý soubor udržují tři časová razítka: kromě atime systém eviduje čas poslední změny v obsahu souboru („mtime“) a čas poslední změny v metadatech („ctime“). Na první pohled nevypadá vedení těchto razítek jako výkonnostní problém; aktualizace mtime nebo ctime vyžaduje opětovný zápis inode na disk, ale operace způsobující tento zápis samy o sobě spočívají v zápisu na disk. Takže by si člověk řekl, že dodatečná režie se v tom jednoduše ztratí.

Ukazuje se, že se najdou situace, kdy tomu tak není – při zápisu do souboru přes mapování vytvořené pomocí mmap(). Zapisovatelné mapované soubory jsou pro operační systém docela výzva: aplikace může změnit jakoukoliv část souboru pomocí jednoduchého zápisu do paměti bez upozornění jádra. Ale jádro se o zápisech musí nějak dozvědět, aby bylo možné upravená data zapsat zpět do trvalého úložiště. Proto, jakmile je soubor označen pro zápis a stránka je přenesena do paměti, jádro (v hardwaru) označí tuto stránku jako pouze ke čtení. Zápis do této stránky způsobí výpadek, takže jádro se dozví, že stránka byla upravena. V tento moment je možné učinit stránku zapisovatelnou, takže další změny už výpadek nezpůsobí; může zůstat zapisovatelnou do doby, než jádro stránku vyčistí zápisem na disk. Jakmile je stránka čistá, musí být opět označena jako jen ke čtení.

Jak Dave Chinner vysvětluje, problém je následující: jakmile jádro obdrží výpadek stránky a učiní stránku zapisovatelnou, tak musí aktualizovat časová razítka souboru a u některých systémů souborů i čítač revize souboru. K tomu dochází synchronně v transakci systému souborů během procesu obsluhy výpadku stránky a umožňování zápisu. Proto se rychlá operace změny stránky na zapisovatelnou stává náročnou operací na systému souborů a dochází k tomu vždy, když aplikace zapíše do čisté stránky. Pokud aplikace zapisuje mnoho stránek, které byly namapovány do paměti, tak bude následkem velké zpomalení. A většina tohoto úsilí je zbytečná: změny razítka se vzájemně přepisují, takže přežije jen ta poslední.

Shodou náhod má Andy Lutomirski aplikaci, na kterou tento problém těžce dopadá. O jeho předchozím úsilí výkonnostní problém vyřešit – MADV_WILLWRITE – se nedávno psalo tady. Není divu, že současné chování okolo aktualizací mtime a ctime se mu nezamlouvá. Navíc tvrdí, že současné chování je v rozporu se Single Unix Specification, které říká, že tato razítka musí být aktualizována mezi jakýmkoliv zápisem do stránky a buď následujícím voláním msync() nebo zpětným zápisem daných dat. Říká, že jádro aktuálně požadované chování neimplementuje.

Zejména poukazuje na to, že razítko je změněno po prvním zápisu do dané stránky. Po tomto prvním použití zůstává stránka zapisovatelnou a jádro nebude vědět o dalších úpravách, dokud nebude stránka zapsána. Pokud stránka zůstává v paměti dlouho (řadu sekund) před zápisem na disk – jak se často stává – pak bude razítko nesprávně ukazovat čas prvního zápisu, nikoliv posledního.

Ve snaze opravit problémy s výkonem i správností připravil Andy sadu patchů, které mění to, jak jsou aktualizace časových razítek řešeny. V tomto novém návrhu se časová razítka neaktualizují v moment, kdy je stránka učiněna zapisovatelnou; namísto tohoto je v příslušné struktuře address_space nastaven nový příznak (AS_CMTIME). Někdy v budoucnu pak jádro zavolá novou operaci flush_cmtime(), která systému souborů řekne, že časy inodu by měly být aktualizovány; k tomuto volání dojde v reakci na zpětný zápis nebo volání msync(). Proto pokud dojde k úpravě tisíců stránek před zpětným zápisem, všechny aktualizace časových razítek budou zjednodušeny do jediné transakce, což operaci podstatně urychlí. Navíc razítko bude odpovídat času poslední úpravy namísto první.

Kvůli tomtu přístupu se vynořily nějaké připomínky. Jedni mají obavu, že při ošetřování časových razítek a čísel revize systémů souborů exportovaných přes NFS platí přísné požadavky. Klienti NFS používají tato razítka k tomu, aby se dozvěděli, kdy jsou cachované kopie zastaralé; pokud jsou aktualizace razítek odkládané na později, je tu riziko, že by klient mohl po nějakou dobu pracovat se starými daty. Andy tvrdil, že při současném přístupu mohou razítka být špatně ještě mnohem déle, takže jeho patch představuje zlepšení, i když není dokonalý. David Lang navrhl, že dokonalosti by bylo dosaženo tím, že by se časová razítka aktualizovala v paměti při prvním zápisu, ale nedocházelo by k zápisu na disk; Andy v tom vidí přínos, ale ještě to neimplementoval.

V době psaní tohoto textu se reakce na tuto sadu patchů dotýkaly hlavně implementačních detailů. Andy bude v patchi muset změnit řadu věcí; je potřeba implementace v systémech souborů dalších než jen ext4 a rozšířit balíček xfstest, aby bylo dokázáno, že to funguje správně. Ale hlavní myšlenka už není kontroverzní. Pokud komunita neobrátí svůj postoj, pak se rychlejší obsluha výpadků u stránek mapovaných na soubor dostane do hlavní řady brzo.

Diskuse k tomuto článku

[x14]

Jak je to tedy teď s tím (tou?) exFAT?

Teď to může kdokoliv kdekoliv jakkoliv (samozřejmě v rámci licence GPL2) použít? Microsoft k tomu nic nenamítá? Ty jejich licenční podmínky tímto (bez jejich přičinění) padají?

[blb]

Pokud je to patentovane, je u plne jedno jak moc GPL je takova poskytnuta implementace.

Snad jen v posledni dobe na Novem Zealande byste s tim uspeli.

Nadruhe strane kde neni zalobce, neni soudce. Tady pokud se exFAT nerozsiri, nikdo nebude prudit. Pokud ho vsak adoptuji vsichni vyrobci fotoaparatu a ruznych jinych gadgets, potom majitel patentu prijde (cira spekulace) a bude chtit sve vypalne.

Podle meho nazoru je takova GPLed exFAT dobra jen proto, abyse jako trojsky kun dostala do Androidu a rozsirila do vsech moznych zarizeni.

Jake jsou vlastne vyhody exFAT oproti jinym FS na trhu? Existuje open source bezpatentova alternativa?

[x14]

Díky za odpověď, tak nějak jsem tušil, že licence ještě nic neřeší.

Výhody exFAT? Když jsem řešil, čím formátovat média, na kterých přenáším data mezi Windows <-> Linux, tak jsem ihned zavrhl FAT32 (max. velikost souboru 4GB) i EXT (implementace na Windows jsou slabé). Nakonec jsem skončil u NTFS, ale kdyby byla na Linuxu exFAT, tak bych možná používal ji. Předpokládám, že implementace a nároky exFAT budou menší než už u pokročilých systém souborů jako jsou EXT nebo NTFS... Ale pokud není exFAT rozšířena, tak nemá výhody žádné.

[Pjenkys]

Imho těžko může Microsoft někoho soudit za patenty. To byste museli používat kód Microsoftu, pokud má Samsung vlastní implementaci, pak Micorost nemůže říct ani popel ne? Navíc si nejsem jistej, jestli by s takovou žalobou někde vůbec uspěl...

[pavlix]

Imho těžko může Microsoft někoho soudit za patenty. To byste museli používat kód Microsoftu

Po tomtu příspěvku nelze než odkázat na nějakou základní literaturu o (softwarových) patentech.

[chrono]

Použiť to môže ktokoľvek, ale predpokladám, že ak pôjde o väčší subjekt, Microsoft bude vyžadovať platenie licenčných poplatkov.