Jaderné noviny - 19. 3. 2015: Změny ve virtuálním souborovém systému, minulost a budoucnost

5. 7. 2015 | Redakce | Jaderné noviny | 2133×

Stav vydání jádra. Citáty týdne. Změny ve virtuálním souborovém systému, minulost a budoucnost.

Stav vydání jádra

Aktuální vývojové jádro je 4.0.rc4, vydané 15. března. Linus k tomu řekl: "Nic zvláštního se neděje. Shortlog je otevřený, myslím, že na to, v jaké fázi cyklu jsme, si vedeme dobře."

Stabilní aktualizace: 3.19.2, 3.14.36 a 3.10.72 byly vydané 18. března.

Kdbus na dobré cestě pro 4.1

Greg Kroah-Hartman přidal strom kdbus do linux-next se záměrem sloučit jej v průběhu příštího začleňovacího okna. "Ten kód byl přepracován a přezkoumán již mnohokrát, poslední kolo bylo bez závad, takže je ve frontě na sloučení do verze 4.1-rc1."

Změny ve virtuálním souborovém systému, minulost a budoucnost

Zatímco většina letošního summitu Linux Storage, Filesystem and Memory Management byla věnována diskuzi o subsystému, některá další témata vyvolala takový zájem, že bylo třeba je projednat na plenárních zasedáních. Al Virova přednáška o vývoji virtuálního souborového systému kernelu (VFS) patřila k těmto tématům. Bez VFS by se toho v systému moc nestalo. Tak či onak, v rychle se vyjíjejícím kernelu, je třeba rychle měnit i VFS.

Jedna z věcí, kterou se ještě, navzdory přáním, nepodařilo uskutečnit, je zajištění lepší sady systémových volání, které by nahradily mount(). Al na tom sice pracoval, ale jeho patche byly zamítnuty ještě než mohly být revidovány. V této oblasti se o pokroku nedá mluvit. Na druhou stranu se trochu podařilo zapracovat na vzniku systémového volání revoke(). Plné přijetí je ještě daleko, ale něco se již podařilo udělat.

Více se pracovalo na přechodu k iov_iter interface. Al doufá, že než se uzavře začleňovací okno 4.1, bude přechod z aio_read() a aio_write() (část asynchronní implementace I/O) na iov_iter dokončen. Některé instance stále potřebují převedení, ale Al je toho názoru, že již nejsou žádné významné překážky.

V minulém roce se konverze iov_iter dočkaly send and recieve cesty síťového zásobníku. Stále chybí sendpages(), ale vypadá to, že v cestě nejsou žádné kompilace. Konverze systémového volání splice() bude mnohem těžší. Kód na straně zápisu byl již téměř celý vyměněn - s jednou výjimkou: Filesystem in Userspace (FUSE). Potíž s FUSE je zero-copy, přesouvání stránek přímo mezi splice() bufferem a cache stránky.

Když byl splice() do kernelu přidán poprvé, bylo "kradení stran" původně záměrem; šlo o užitečnou optimalizaci. Nevýhodou byla spousta chyb, například zmatek v kódu souborového systému v okamžiku kdy se aktualizované stránky dostanou do cache stránky. Nick Piggin tuto vlastnost odstranil v roce 2007 a od té doby se nikdo neměl k tomu ji tam vrátit. Al poznamenal, že Nick popsal některé z problémů ve své zprávě, ale jsou další, ke kterým se Nick v minulých letech nedostal a zdá se, že zůstanou tajemstvím, dokud je někdo znovu neobjeví.

Operace zero-copy jsou ve splice() zablokované s jednou výjimkou: FUSE. Problém, který ovlivňoval kradení stránek u jiných souborových systémů se u FUSE neobjevuje, takže nebyl důvod k zablokování. Kromě toho FUSE vyžaduje zero-copy operace, jina dochází k problémům s výkonem. Toto je důvod, který FUSE zatím ochránil od konverze na iov_iter. Alovým řešením problému by bylo obnovení zero-copy pro všechny případy, to však bude vyžadovat další výzkum.

Strana read (zastoupená splice_read() fire_operations) bude pravděpodobně konvertována někdy letos. Al je překvapen, kolik instancí iovec (předchůdců iov_iter) v kernelu nadále zůstává. A jen tak z něj nezmizí, ale používají se stále méně.

Další novou změnou, mimo virtuální souborový systém, je struktura nameidata, která se stane zcela neviditelnou. Bude definována v kódu VFS. Al by se časem rád zbavil ukazatelů k této struktuře a místo ní zavedl používání ukazatelů ze struktury úloh. Tato změna by neměla výrazně ovlivnit kód mimo VFS, ale Al považoval za dobré toto zmínit, jelikož to poškodí některé patche.

Pokračují i práce na projektu, který má za úkol zbavit se mnoha variant d_add(), základní funkce, která přidává záznam struktuře adresáře (dentry) do dentry cache. Jedna z těchto variant, — d_materialise_unique() — byla odstraněna již ve verzi 3.19. Jiné, jako například d_splice_alias() zůstaly. Ideální by bylo mít jediný základní prvek, který by sdružil dentry a inode. Matthew Wilcox se zeptal, zda by jiné variant stále měly význam pro účely dokumentace, ale Al mu odpověděl, že v takových případech by se mělo pracovat důrazně.

Několik dalších nedávných změn zahrnuje unmount souborových systémů při neplatnosti a lepší zpracování vypínání. Změna při odpojení (unmount) způsobuje automatické odebrání souborových systémů, je li zrušen přípojný bod - tato změna byla zařazena před několika měsíci. Velkou změnou je zpracování vypínaní souborového systému, které je nyní zpožděné a odehrává se v (shallow) zásobníku. To by mělo rozptýlit obavy o přetékání zásobníků, které by se jinak mohly objevit během vypínání.

Poslední Alovo téma se týkalo předávání informací o procesu BSD. Co se stává, když začne předávání informací do souboru a dojde k odpojení (unmount) základního FS. Na BSD systému způsobí odebrání EBUSY chybu. Na Linuxu se "někdo rozhodl, že bude nápomocný" a myslel, že by bylo hezkým gestem automaticky zastavit předávání a povolit odpojení (unmount). Tato taktika vypadá užitečně, ale má háček. Vytváří situace, kdy otevřený soubor na souborovém systému nezpůsobí zaneprázdnění souborového systému. To vedlo ke spoustám zajímavým souběhům "race conditions" zpět do roku 2000 nebo tak nějak. Podle Ala je to "pořádný oříšek".

Tento mechanismus byl z kernelu odebrán. Na jeho místě je mechanismus, který umožňuje přidat objekt do struktury vsmount (která zde zastupuje připojený souborový systém); tento objekt podporuje pouze jediný způsob: kill(). Tyto "pin" objekty zůstávají, dokud nezmizí konečný odkaz vfsmount a v tomto okamžiku jsou volány jejich funkce kill(). Jedná se tedy o čistý mechanismus pro provádění čištění, když zmizí souborový systém.

První využití tohoto mechanismu se využívá při ukončování BSD zápisu procesu informací. Dobré využití se nabízí také v případě, že je třeba odpojit velký strom s několika souborovými systémy. Pokud jsou na sobě souborové systémy závislé, lze vložit pin a ujistit se, že bude vyčistění provedeno ve správném pořadí. Tato funkcionalita, nachází se v fs/fs_pin.c vypadá užitečně, ale, jak poznamenal Ted Ts´o, je v současné době nezdokumentovaná. Al skončil svůj výstup s potvrzením (uznáním), že některé komentáře budou dalším uživatelům k užitku.

       

Komentáře

[Lol Phirae]

To vedlo ke spoustě zajímavým závodům zpět do roku 2000 nebo tak nějak

"That has led to a lot of interesting races dating back to 2000 or so"

Dej si ránu do palice. Fakt už.

[Ja]

Jaký je správný význam té věty?

[m.s.]

Řeč je o chybách typu race condition (česky souběh), pocházejících někdy z roku 2000.

[Bystroushaak]

Možná už dosáhla složitost kernelu takové míry, že porušila časové kontinuum. Vývojáři tak můžou z nudy závodit zpět do roku 2000, nebo tak nějak, schválně kdo tam doletí rychleji.

[m.s.]

Teda nikdy jsem úroveň překladu JN nekomentoval, ale tady mi to nedá, protože půlka textu už prakticky nedává smysl.

Autore, nutnou (nikoliv postačující) podmínkou kvalitního překladu je tento postup:

1. Překladatel si důkladně přečte celý původní text, nejlépe několikrát po sobě, aby ho znal jako celek.
2. Než začne cokoliv překládat, překladatel musí do posledního detailu pochopit obsah textu! Tedy musí porozumět sdělení celého článku a jednotlivých odstavců, musí mít poměrně hluboké znalosti problematiky a terminologie v obou jazycích, měl by znát širší kontext, historické souvislosti atd. Proto taky články o nukleární fyzice obvykle překládá nukleární fyzik a ne dejme tomu gynekolog.
3. Překladatel volně převypráví vlastními slovy obsah původního článku. Samozřejmě tak, aby zůstaly zachovány veškeré sdělované informace a ideálně i styl sdělení, ale zároveň aby překlad respektoval větnou stavbu, gramatiku a terminologii druhého jazyka.

[Sid]

Ako toto preklada kto? sorry ale nie vzdy plati, ze je lepsie aspon to skusit ako nerobit nic. Su situacie ako tato ked nerobit nic je 100x lepsie ako tu poslat takyto text. Ked uz som sa rozhodol prekladat nieco comu zjavne nerozumiem tak aspon to poslem pred publikovanim niekomu kto to poopravuje.

[Lol Phirae]

Nejhorší je, že ten člověk tomu nejen nerozumí odborně a umí mizerně anglicky, ale neumí ani pořádně česky. Ta v prvním postu citovaná "perla" je blbě i česky, protože sice něco vede ke komu, čemu (dativ), ale spousta koho, čeho (genitiv). O notoricky tragické interpunkci ani nemluvě.