overlayfs na cestě do jádra

Lwn.net informuje, že v rámci rc vydání linuxového jádra 3.18-rc2 byl (konečně) začleněn souborový systém overlayfs. Jde o tz. sjednocující souborový systém, který umožňuje zkombinovat několik souborových systémů do jednoho.

28.10.2014 14:30 | marbu | Nová verze

Komentáře

[Jiří J.]

Bylo na čase, po těch .. 10 (?) letech používání pro live distribuce.

(no dobře, až na fedoru/device-mapper)

[r4in]

To zní pěkně, než se něco posere. Pak z takové partition vydolovat ztracená data bude určitě sranda.

[pavlix]

?

[mankind_boost]

Je to neco jako aufs...

[vlastikroot]

Ja to pouzivam na tmpfs

[Jiří Šlachta]

Podle mne je zase toto mechanismus, který je pro takové "kazící" systémy ideální. Read only souborový systém na SD kartě, overlay na externím disku, když se disk pokazí, tak se vymění a jede se dále. Ideální pro případy, kdy víte, že s Vaším systémem budou pracovat lidé, kteří zrovna ajťáci nejsou.

Please, replace the harddrive, something bad happened!

A v záloze budete mít náhradní disk s konfigurací. Je to blbuvzdorné a umožňuje to jednodušší diagnostiku. Rozhodně lepší, než aby neznalí si hráli s nástroji na úrovni blokového zařízení nebo souborového systému.

Rozhodně to má svůj "use case".

[little.owl]

+1

Tak je to pouzito v OpenWrt jiz nejaky cas k transparentni integraci dat ulozenych ve flash pameti, viz zde.

[pavlix]

Navíc je tam krásně řešený rescue režim.

[Sten]

overlayfs je virtuální, spojující jiné oddíly. Takže dolovat data budete jen z těch oddílů pod tím, kde může být libovolný či váš oblíbený souborový systém.

[Kvakor]

overlayfs jede na úrovni VFS, overlay/copy-on-write na úrovni blokových zařízení je v jádře už dávno - přes device mapper jako snapshooty (volby snapshot a lowerdevice). Nicméně v případě havárie bude read-only zařízení zcela nedotčené, protože všechny zápisy jdou na druhé zařízení (kde je pouze bitmapa bloků clean/dirty a pak následné dirty bloky), v nejhorším případě se tedy přijde o všechna "nově" zapsaná data (což je většinou přesně takové chování, které chceme).

[Conscript89]

Tak na to se dnes napiju Huraaaaaaa

[Aleš Kapica]

Sláva!

[Bedňa]

Nechcel by si nám tu vysvetliť prečo sa raduješ Ako to vlastne funguje?

[little.owl]

Here.

[petr_p]

Pro všechny, co to vykřikují sláva, doporučuji si tento dokument přečíst, aby věděli, co všechno nebude fungovat. Například atomický rename.

[Aleš Kapica]

Jak se projevuje nefunkční atomický rename?

[Pavel Píša]

Určitě není atomický copy-up, z toho vyplývá, že při použití perzistentního úložiště pro RW vrstvu může při přerušení operace být při příštím bootu i nemodifikovaný soubor, který byl předtím otevřený pro RW, v overlay změněný. Obecně je škoda, že jen RW otevření, kde je v kódu RW zbytečně (spíš chyba aplikace) nebo kde nakonec k žádné modifikaci nedojde (databáze) se kopíruje do RW úložiště. Co se týče rename, tak jsem moc nezkoumal aktuální implementaci, ale whiteout používá na úrovni RW větve RENAME_EXCHANGE za whiteout. Na zavedeni RENAME_EXCHANGE, RENAME_WHITEOUT a syscallu renameat2() Miklos Szeredi spolupracoval s mainline. Pokud tedy FS v RW větvi tyto operace provede atomicky, tak by nekonzistentní stav při mazání nastat neměl. Nejspíš lze naimplementovat i copy-up tak, že nejdříve zapíše soubor pod jiným názvem a pak ho přehodí v RW větvi atomicky (pokud to daný FS umí) ... tak kód ovl_copy_up_locked právě toto dělá, použije workdir viz ovl_lookup_temp(). Takže zajištění konzistence je celkem silné.

Na druhou stranu jsou zde zásadní omezení, pokud jsem něco nepřehlédl, tak pokud někdo udělá mmap nebo open v režimu RO a pak dojde k copy-up a změně souboru, tak ten co ho dříve otevřel v RO, uvidí stále starý obsah. To je celkem nepříjemné. Dále je problém se změnou vlastníka souboru při otevření v RO režimu a pár dalších corner casů. Takže adresáře /run a /tmp je rozumné směrovat do jednoduchého tmpfs, nikoliv nechat práci na overlay. Stejně tak home a reálná pracovní data dekstopů a virtuálů směřovat na samostatný FS.

Ale pro root a zajištění perzonalizace systému ze společného image je overlayfs výhra. Tady na atomičnosti na úrovni úložiště/RW větve opravdu nezáleží - je to tmpfs.

Na OpenWRT a dalších je nakonec úroveň zachování konzistence overlayfs s perzistentní RW větví rozumná a vždy je zde možnost vyvolat watchdogem nebo jinak při nekonsistenci vyvolat boot v čistém základním nastavení bez namontovaného overlaye a RW větev nějak opravit. Pokud systém alespoň jakžtakž běží i v overlay módu, tak je možné změny v RW větvi promazat a pak provést reboot. Ale při některých klíčových binárkách a knihovnách v RW větvi to již může být problém.

Jinak budu rád, když nás někdo upozorní na další možná omezení a problémy. Zatím jsem přesvědčený, že se jedná o to, co potřebujeme.

[little.owl]

RW access je v plno kodu zbytecne.

[omg]

selinux policy toho dost vycistilo... pokud se na to ovsem nekdo nevybodl jeste driv nez zacal nejakym zjednodusenim navrhu policy.

[Jindřich Makovička]

Spoustě lidí bude stačit, pokud jsou ty operace atomické z pohledu běžících procesů. Pokud se overlay náhodou rozbije při pádu systému, holt se inicializuje znova :)

[little.owl]

A clovek jen prijde o data.

[little.owl]

Tam jsou i jine veci:

When a file in the lower filesystem is accessed in a way the requires write-access, such as opening for write access, changing some metadata etc., the file is first copied from the lower filesystem to the upper filesystem (copy_up).

Takze write-access a zmena 1B v souboru v dolni vrstve zpusobi v prvnim kroku kopirovani treba 100MB dat do vyssi vrstvy; to je docela limitujici.

[Kvakor]

Tam, kde by se dělaly často podobné operace, jde použít device mapper (jak už jsem psal výš), potom se budou zapisovat jen změněné bloky. Ale u typického využití nebude toto omezení tolik vadit, protože při něm se většinou jedná o soubory s velikostí v řádu bytů až kilobytů.

[Aleš Kapica]

Ale u typického využití nebude toto omezení tolik vadit, protože při něm se většinou jedná o soubory s velikostí v řádu bytů až kilobytů.

Tak to je. Většinou se to dá obejít tím, že se lépe promyslí výchozí strategie. Viz kupř. jak jsem řešil nad overlay virtuály pro VMware Player. Kdyby se neudělal snapshot, tak by pochopitelně soubor s virtuálním diskem zaplácnul veškerou volnou paměť a bylo by po ptákách. Takhle se změny vejdou do poměrně malého souboru.

Kromě toho umožňuje overlay řešit takovou situaci i jinak. Kupř. tak, že složím dohromady blokové zařízení s výchozími daty s nějakým jiným - může jím být lokální image připojený přes loop, nebo vzdáleně vypublikovaný přes xNBD aj. Fantazii se meze nekladou.

[Conscript89]

Jasne, to jde pokud mas ovsem blokove zarizeni s RW fs, nad NFS nebo ISO filesystemem si ale takto overlay udelat nemuzes.

[Aleš Kapica]

Jak to že ne? Používáme ho téměř výlučně nad NFS.

[Conscript89]

Device mapper reseni funguje nad blokovymi zarizenimi, ne? Jak ziskam z nfs share blokove zarizeni ktery pak muzu v dm pouzivat? Jediny co jde tak nejaky soubor na NFS hodit na loopback a na tom pak pomoci dm operovat (stejne tak jak to dela anaconda pri nfs instalaci), ale nad samotnym nfs to neudelam. Pokud jo, tak se neco novyho aspon naucim.

[Aleš Kapica]

Abych to upřesnil - namountuješ jako rw zařízení kus paměti jako tmpfs.

[Conscript89]

RW blokove zarizeni neni problem, to si muzu presne takto vycucat z prstu. Problem je, ze u DM musi byt ten RO blokove zarizeni a navic na nem musi byt FS ktery podporuje zapis. Tak to bylo i mysleno, NFS byl priklad neblokoveho mountu a ISO9660 zase priklad FS nepodporujiciho zapis. Oba tyto pripady muze resit overlayfs.

[Aleš Kapica]

Vždyť právě o overlayfs píšu. Proto také ono zvolání. Evidentně jsme si neporozuměli.

[Pavel Píša]

+1 - aneb pro znalé zvolání "Sláva" zcela stačí. Pokud ovšem další review a případné kritické útoky tentokráte pull request vydrží a do mainline tentokráte již opravdu doputuje ... tak "fs/overlayfs/*" již v v3.18-rc2 opravdu je .. tak 2x Sláva.

Aleš je tento týden myslím mimo školu, tak přikládám odkazy na jím připravované administrátorské manuály/příručky pro infrastrukturu používanou například v laboratořích na naší katedře.

Překrytí systémového disku - overlay filesystem

Jak vytvořit bezdiskový stroj s operačním systémem GNU/Linux

Bohužel všechna do teď používaná řešení (unionfs, aufs, overlayfs) byla mimo hlavní vývojový strom. Aufs většinou je k dispozici jako balíček pro Debian, ale pro Raspbian například není. Přitom co se týče zamykání a kombinování s RT jádry - která jsou pro řízení nutností - nemám z aufs dobrý pocit. Overlayfs nabízí sice o něco méně featur, ale je psaný tak, aby byl začlenitelný a procházel a prochází kompletním review core VFS vývojářů. Přesto, pokud je mimo strom, tak se s ním pracuje (rebázují patche na používaná jádra s bezečnostními opravami atd.) celkem obtížně. To by se teď mělo změnit. Do této chvíle nakonec většinou používáme aufs.

Použití RO fs pro Raspbian (zatím s aufs) jsem řešil pro jednu firmu zde a soubor s dokumentací je zde. Skripty jsou připravené i na overlayfs, ale ten jsem na Raspberry netestoval.

O všech těchto našich aktivitách jsme již na ABClinuxu informovali a naše řešení systémů pro laboratoře jsme i demonstrovali před několika lety na InstallFestu.

[Petr Ježek]

Využitelnost především pro TR systémy. Dále move verze, ale to vše je těžká minorita. Příklad s náhradami disků moc přesvědčivý není, protože je tu k dispozice třeba NIX. Pro praxi je více cest, jak dosáhnout bezpečnější a efektivnější správy dat v souborech.

[Bedňa]

Dík chlapi, tak využitie na to nemám, ale už chápem že sa niekto z toho môže tešiť

[Mike]

Hallelujah!!!

[Václav "Darm" Novák]

Safra, jako na zavolanou