Jaderné noviny – 19. 11. 2014: Představení lazytime

20. 12. 2014 | Tadeáš Pelech

Články - Jaderné noviny – 19. 11. 2014: Představení lazytime  

Aktuální verze vývojového jádra: 3.18-rc5. Citáty týdne. Představení lazytime. Obory názvů řídicích skupin.

Obsah

• Aktuální verze vývojového jádra: 3.18-rc5
• Citáty týdne
• Představení lazytime
• Obory názvů řídicích skupin

Aktuální verze vývojového jádra: 3.18-rc5

Aktuální vývojové jádro je 3.18-rc5. Vývojové jádro 3.18-rc5 vyšlo dne 16. listopadu (oznámení). Linus k tomu řekl:

Sice ještě máme pár nevyřešených problémů, ale situace vypadá docela normálně. Ještě stále nám zbývá pár týdnů před finální verzí a čím víc můžete testovat, tím spíš se nám všechno podaří.

Stabilní aktualizace: Aktualizace verzí 3.17.3, 3.14.24 a 3.10.60 byly vydány dne 14. listopadu.

Citáty týdne

Myslím, že nejsem moc velký gambler. Dávám přednost záruce stabilního pomalého pokroku před jackpotem skoro každý den.

– Linus Torvalds

Kromě toho, moje Kouzelná kříšťálová koule(tm) říká tohle:

„Závodníci, kteří používají $FASTEST_DISTRO_OF_THE_MONTH a zamořují fóra technických závodníků, vždycky ladí atime na maximální warp rychlost. Jeden z nich si spojí aktualizace atime a lazytime a zapne tak lazytime. Pak napíšou do fóra o tom, jak jejich test bonnie++ běží o 3,4 % rychleji. Ale jen když stojí na hlavě, šilhají a vypláznou jazyk. A že by to tak měl udělat každý, protože je to jednoznačně lepší.

Fóry závodníků po celém světě se rychle začnou šířit souhlasné příspěvky a Google pak začne tyto příspěvky vracet jako první při hledání výrazu lazytime. Tak vznikne cargo kult uživatelů, kteří dělají stojky a používají „-o noatime,nodiratime,lazytime“, protože to tak udělal ten první. A všichni, kdo to zkusili po něm, se shodují, že je to jednoznačně lepší.

Za deset let budeme lidem stále ještě vysvětlovat, že údaje z bonnie++ jsou nesmyslné, parametr nodiratime je nadbytečný, když zadáte noatime, že oba jsou nadbytečné, když zadáte lazytime, a že když stojíte na hlavě a šklebíte se, jen vypadáte jako idiot a bolí vás hlava.

Mezitím bude Eric sedět v koutě a mumlat si tiše pro sebe o tom, že stále ještě není Sed pro Google API, který by mu umožnil revidovat historii tak, aby lidé nenacházeli staré příspěvky o zlepšení výkonu, pokud se postavíte na hlavu, budete se šklebit a používat parametry noatime,nodiratime,lazytime...“

– Dave Chinner

Představení lazytime

POSIX-kompatibilní systémy souborů udržují tři časová razítka pro každý soubor, odpovídající času poslední změny v metadatech souboru nebo obsahu (známé jako jeho „ctime“), změny v obsahu souboru („mtime“) a přístupu k souboru („atime“). První dvě časová razítka jsou obecně považována za užitečná, ale „atime“ bylo dlouho pokládáno za příliš nákladné na výhody, které poskytuje. V současných systémech existuje volba připojení (s názvem „relatime“), která zmírňuje nejhorší problémy způsobené atime, ale je s ní spojeno několik problémů. Nová volba „lazytime“ by mohlo nahradit relatime a poskytnout nejlepší možné řešení.

Problém s atime je v tom, že by měl být aktualizován při každém přístupu k příslušnému souboru. Aktualizace atime vyžaduje zápis inodu souboru zpět na disk, takže sledování atime v zásadě promění každou operaci čtení na zápis. Při mnoha zátěžích může být vliv na výkon výrazný. Navíc existuje jen několik programů, které atime využívají nebo závisí na jeho aktualizaci. Proto před deseti lety bylo běžné připojovat systémy souborů s možností „noatime“, která zcela zakazuje sledování doby přístupu.

Problém je samozřejmě v tom, že „několik programů“ není totéž jako „žádné programy“; ukazuje se, že skutečně existují nástroje, které by v případě vypnutého sledování atime selhaly. Klasickým příkladem jsou poštovní klienti, kteří používají atime k určení, zda byla poštovní schránka od posledního doručení pošty přečtena. Po nějaké diskuzi komunita jádra přidala do vývojového cyklu verze 2.6.20 možnost připojení „relatime“. Možnost relatime způsobí, že většina aktualizací atime bude potlačena, ale umožní aktualizaci atime, pokud je aktuálně zaznamenané razítko atime před aktuálním ctime nebo mtime. Později byl relatime vylepšen tak, aby aktualizoval atime každých 24 hodin (ale samozřejmě jen v případě přístupu k souboru).

Relatime funguje docela dobře pro většinu systémů, ale stále se najdou takové, které by chtěly lepší sledování atime bez zhoršení výkonnosti. Některým uživatelům také vadí fakt, že relatime, přes všechny výhody, způsobí, že systém není plně kompatibilní se specifikací POSIX. Z větší části se lidé smířili s drobnými nedostatky v relatime (nebo s nároky aktualizací atime na systém), ale nyní se na obzoru objevila alternativa.

Ta má podobu volby připojení lazytime, kterou předložil jako opravu specifickou pro ext4 Ted Ts'o. Pokud je povolena možnost lazytime, systém souborů bude aktuálnost atime udržovat v inode souboru v paměti. Ale tento inode nebude zapsán na disk, dokud se neobjeví nějaký jiný důvod nebo dokud nebude samotný inode uvolněn z paměti. Dúsledkem toho je atime, který je stále aktuální z hlediska jakéhokoli programu spuštěného v systému. Verze atime uložená na disku však může výrazně zaostávat za realitou a aktuální atime může být v případě pádu systému ztracen.

Dave Chinner rychle poukázal na to, že zatímco tato možnost vypadá celkem užitečně, systém souborů ext4 nemusí být pravděpodobně nejlepším místem k jejímu zavedení. Pokud by byl příznak lazytime zaveden do vrstvy virtuálního systému souborů (VFS), pak by byl k dispozici pro všechny systémy souborů, nejen ext4. A mohl by, což je nejdůležitější, ve všech fungovat stejným způsobem. Ted souhlasil, že implementace VFS by mohla dávat smysl; další verze této opravy bude téměř jistě na této úrovni implementována.

Dave také navrhl, že neomezené odkládání zápisu aktualizací atime není příliš vhodné:

Byli bychom ale blázni, kdybychom ignorovali vývoj relatime, který ve své původní podobě nikdy naktualizoval atime, dokud nedošlo k aktualizaci mtime nebo ctime. 3 roky po zavedení byl relatime změněn tak, aby omezil zpoždění aktualizací na 24 hodin (než byla tato hodnota nastavena jako standardní), aby aplikace, které vyžadují pravidelné aktualizace časových razítek, nepřestaly bez upozornění pracovat.

Ted byl opět k této myšlence svolný, takže příští verze bude pravděpodobně zapisovat aktualizované hodnoty atime nejméně jednou za 24 hodin. Bez této změny by mohly být aktualizace atime uchovávány v paměti i po celé měsíce, například v databázovém serveru, který udržuje své soubory otevřené bez omezení.

A konečně je tu otázka, zda by se lazytime měla stát výchozí možností připojení systému souborů. To splňuje POSIX (nebo, přesněji, po další jedné či dvou opravách) bez vynaložení nákladů na normální aktualizaci atime. Proto se to jeví jako lepší volba než relatime, což je aktuální výchozí nastavení. Zdá se, že Ted by chtěl změnit výchozí nastavení co nejdříve, zatímco Dave je trochu více znepokojen regresemi a raději by počkal několik let, než se všechno prověří v praxi. To vedlo k otázce, zda bude mezitím tato funkce dostatečně otestována. Ale, jak poznamenal Dave, o tuto funkci bude pravděpodobně dostatečný zájem a lidé ji budou chtít vyzkoušet.

Teprve budoucnost ukáže, jestli to tak bude; relatime funguje pro většinu uživatelů docela dobře, takže v podstatě žádný velký dav lidí nečeká, až si bude moct vyzkoušet novou možnost připojení systému souborů. Ale nakonec se ty dobrodružnější distribuce pravděpodobně odhodlají; potom by se nejspíš měly v poměrně krátké době projevit všechny případné skryté problémy. Pokud se tedy možnost lazytime stane výchozí někdy v roce 2016, měla by být opravdu otestována a mělo by být jasné, že pracuje bez problémů.

Obory názvů řídicích skupin

Kontejnery v Linuxu používají řídicí skupiny (cgroup) a obory názvů k izolaci sady procesů do virtuálního systému na úrovni operačního systému (na rozdíl od izolace na úrovni hardwaru s KVM). Ale v současné době nejsou samotné cgroups virtualizované. To vede k řadě problémů pro správce kontejnerů (např. LXC nebo Docker.), protože procesy uvnitř těchto kontejnerů vidí globální prostředí cgroup. Nedávná oprava se snaží tyto problémy opravit tím, že vytvoří nový obor názvů pro cgroup.

Aditya Kali na konci října zveřejnil verzi 2 sady oprav pro obor názvů cgroup. Je založena na práci sjednocené hierarchie cgroup Tejuna Hea a je určena k řešení několika problémů kontejnerů. Například, když úloha zkoumá soubor /proc/self/cgroup, v současné době vidí plnou cestu cgroup z globální hierarchie cgroup, což prozrazuje informace o hostitelském systému. Tyto informace ztěžují migraci kontejnerů mezi systémy (pomocí kontrolního bodu a obnovení v uživatelském prostoru neboli CRIU), protože všechny názvy by musely být jedinečné v rámci všech systémů, aby nedocházelo k žádným kolizím s názvy v novém systému. Navíc nástroje pro správu spuštěných kontejnerů v kontejnerech (jejich vnoření) je obtížné, protože dostupné informace nejsou relativní vzhledem k existujícímu kontejneru.

Základní myšlenkou sady oprav je, že proces může zavolat unshare() pomocí příznaku CLONE_NEWCGROUP, aby vstoupil do nového oboru názvů cgroup. Jakmile to udělá, už neuvidí globální hierarchii cgroup, ale místo toho uvidí sebe v kořenové cgroup. Kali v první opravě popsal, jak by to vypadalo:

    $ cat /proc/self/cgroup
    0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/c_job_id1

    $ ~/unshare -c  # calls unshare(CLONE_NEWCGROUP) and exec’s /bin/bash

    # Z nové cgroupns proces vidí, že je v kořenové cgroup
    [ns]$ cat /proc/self/cgroup
    0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/

Podobně /proc/<PID>/cgroup vrátí cestu, která je relativní ke kořeni oboru názvů cgroup (známé jako cgroupns-root). Navíc připojení systému souborů řídicí skupiny (cgroupfs) v rámci tohoto oboru názvů vytvoří z kořene cgroupns kořen připojeného cgroupfs. V podstatě by to bylo vázané připojení podstromu oboru názvů cgroup do cgroupfs (tj. od úrovně cgroupns-root) k přípojnému bodu. V současné době připojení cgroupfs odhalí úplnou hierarchii existujících cgroup, a prozradí tak zbytečné (a matoucí) informace.

Hlavní oblast diskuse o sadě oprav (a jejím předchůdci, verzi 1) se týkala toho, které procesy lze přesunout do oborů názvů cgroup na různých úrovních v hierarchii (např. pod, nad nebo na stejnou úroveň hierarchie). Původní opravy povolily pouze přesun procesů do oborů názvů pod vlastním kořenem cgroupns, ale to bylo považováno za příliš omezující (mohla by nastat situace, kdy by například uživatel root nemohl přesunout proces do konkrétního oboru názvů). Aktuální opravy umožňují vhodně privilegovaným procesům přesunout procesy do oboru názvů cgroup v hierarchii, ale neprovádějí žádný implicitní přesun procesu do jiné cgroup – to musí zařídit proces provádějící přesun. To může vést k relativní cestě v /proc/<PID>/cgroup v závislosti na oboru názvů procesu hledání a na příslušném PID:

    # ns is at '/groups/a', PID 4567 is in a cgroupns at '/groups/b'
    [ns]$ cat /proc/4567/cgroup
    0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/../b

Po provedení těchto změn mohou správci kontejnerů zacházet s vnořenými kontejnery stejně jako na nejvyšší úrovni. Nástroje pro migraci kontejnerů mohou také dělat svou práci bez starostí o kolize názvů v novém systému.

Reakce jsou prozatím docela pozitivní. Proběhly diskuse o různých aspektech této sady oprav, ale nikdo tuto myšlenku zjevně nijak nebrzdí. Naopak, vývojář oborů názvů Eric W. Biederman poznamenal, že tato sada oprav „rozhodně vypadá jako krok správným směrem; o něco v takového nebo podobné formě požaduju pro skupiny cgroup od chvíle jejich začlenění.“ Na této opravě je potřeba dále pracovat, ale dá se čekat, že se nový obor názvů pro cgroups jednou v jádře objeví.

Diskuse k tomuto článku

[luky]

omg, namespaceum se rika jmenne prostory

[jdsulin]

atime je blbost, zrusit :) ... ssd disk killer feature

[moje jméno ;-)]

Ber to tak, ze to je vyuzitelne. Napriklad sa s maznelkou hadas, ze zazalohovanych 400GB serialov nema co na disku robit, ked ich nepozera a ona ti povie "Dokáž!". Bez atime si v prdeli...

[Heron]

Nejsi, prostě přikoupíš disky. Proč řešit 10% velikosti nového disku?

[moje jméno ;-)]

Lebo 400 gigove ssd je kus drahe... A frajerkam/manzelkam sa tazko vysvetluje, ze v notebooku chcu mat male ssdcko a nie narodny archiv na paskovej integrovanej mechanike a ze take data patria na externe ulozisko, ak sa nepouzivaju.

Ale neries, kam maju ist data, ale ako ziskas informaciu o tom, co uzivatel potrebuje naozaj a co si len mysli, ze potrebuje a urcite vyuziva kazdy tyzden...

[vlk]

staci ked mas nejake indexovanie (ako je dnes 'moderne' a bezne) a potom uz sa neda spolahnut ci atime ukazuje tvoj pristup alebo pristup nejakeho indexovacieho robota.

[trubicoid2]

serjijaly se nezalohujou, sosnes znova :)

jinak dejv pekne perlil :)