Jak ojebat overlay

23.1.2016 13:32 | Přečteno: 3010× | Za vším hledej Linux | | poslední úprava: 5.2.2016 11:42

Je to tristní situace. Dlouho a s nadějí očekávaná integrace modulu overlay (původně "overlayfs") má zatím velice rozpačitý výsledek, neboť stále nefunguje nad NFS a jak se zdá, ani u jádra řady 4.5 se situace jen tak nezmění. I když nemohu vyloučit, že je to možná kombinací jaderných modulů a konfigurace jádra Debianu. Nechápu, jakým způsobem, za jakých okolností a proti jakému NFS serveru Szeredi tento modul testuje, protože mi to nefunguje ani u poslední verze jádra ( commit 2c9b3 ), která již má začleněn patch zavádějící parametr 'default_permissions'. Díky němu by měl overlay nad readonly NFS fungovat. Jenže..
Namountovaný NFS adresář vypadá na první pohled OK. Až na jeden detail - žádný soubor nelze otevřít. Ať dělám co dělám, vždy skončím při pokusu o čtení obsahu souboru s hláškou: "No such device or address".

Při umountu v mém buildu jádra se navíc vyblije následující hláška:

[ 1354.255133] BUG: Dentry ffff8800572466d8{i=110f6,n=hostname}  still in use (1) [unmount of overlay overlay]
[ 1354.278404] ------------[ cut here ]------------
[ 1354.303061] WARNING: CPU: 0 PID: 1211 at fs/dcache.c:1436 umount_check+0x75/0x80()
[ 1354.323677] Modules linked in: rpcsec_gss_krb5 ppdev snd_pcm snd_timer snd soundcore joydev evdev serio_raw pcspkr sg acpi_cpufreq bochs_drm tpm_tis parport_pc ttm 8250_fintek parport drm_kms_helper tpm i2c_piix4 drm processor button autofs4 usbhid hid ohci_hcd uhci_hcd ehci_pci ehci_hcd xhci_pci xhci_hcd usbcore usb_common overlay fuse nfs_layout_nfsv41_files nfsv4 dns_resolver nfsv3 nfs_acl nfsv2 auth_rpcgss oid_registry nfs lockd grace fscache sunrpc sr_mod cdrom ata_generic virtio_net ata_piix psmouse virtio_pci virtio_ring virtio libata scsi_mod floppy
[ 1354.432014] CPU: 0 PID: 1211 Comm: umount Not tainted 4.5.0pre+ #1
[ 1354.452553] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
[ 1354.474159]  0000000000000000 000000001f7757f1 ffffffff812f61e9 0000000000000000
[ 1354.496040]  ffffffff8107691d ffff880057246730 ffff8800572466d8 ffff88005722b778
[ 1354.519530]  ffff880057246768 ffff88005722b6d8 ffffffff811f7795 ffff88011b714428
[ 1354.542449] Call Trace:
[ 1354.565390]  [<ffffffff812f61e9>] ? dump_stack+0x40/0x57
[ 1354.587523]  [<ffffffff8107691d>] ? warn_slowpath_common+0x7d/0xb0
[ 1354.610081]  [<ffffffff811f7795>] ? umount_check+0x75/0x80
[ 1354.633026]  [<ffffffff811f72f3>] ? d_walk+0xd3/0x2c0
[ 1354.653874]  [<ffffffff811f7720>] ? dentry_free+0x80/0x80
[ 1354.673811]  [<ffffffff811f8382>] ? do_one_tree+0x22/0x40
[ 1354.694889]  [<ffffffff811f9948>] ? shrink_dcache_for_umount+0x28/0x90
[ 1354.717440]  [<ffffffff811e33ca>] ? generic_shutdown_super+0x1a/0xf0
[ 1354.736584]  [<ffffffff811e36fe>] ? kill_anon_super+0xe/0x20
[ 1354.755015]  [<ffffffff811e3854>] ? deactivate_locked_super+0x34/0x60
[ 1354.773859]  [<ffffffff8120059b>] ? cleanup_mnt+0x3b/0x80
[ 1354.793235]  [<ffffffff810925f1>] ? task_work_run+0x71/0x90
[ 1354.813667]  [<ffffffff8100333a>] ? exit_to_usermode_loop+0xba/0xc0
[ 1354.833053]  [<ffffffff81598790>] ? int_ret_from_sys_call+0x25/0x8f
[ 1354.851096] ---[ end trace 3d7df212d8efa580 ]---
[ 1354.869876] VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds.  Have a nice day...

Třeba někdo chytřejší z vás na jejím základě přijde na to v čem je problém. Nicméně předmětem blogpostu není proč nefunguje modul overlay nad NFS, ale jak se to dá obejít

AUFS ?

Modul aufs jsme dlouhá léta bez problémů používali u jader verze 3.x Jenže ouha! V jádře řady 4.x patrně došlo ke změnám, které činí nad NFS nepoužitelným i tento modul. Ovšem opět - nemohu vyloučit, že za tím vězí výchozí konfigurace jádra Debianu. Při překrytí NFS aufs kolabuje s chybou:

[  204.989454] aufs au_xino_read:711:ls[527]: I/O Error, too large hi13313365865068650304

Update z 5.2.2016: O dva týdny později jsem k této problematice napsal další blogpost - Jak použít pro overlay aufs, kde jsem zmínil to co nepadlo tady, že jde o NFS server nad GlusterFS. A díky řešení jiného problému zjistil, že aufs havaruje kvůli 64bitovým číslům i nodů.

Jak jsem zjistil z jeho dokumentace, podstata problému je v tom, že aufs provádí přemapování inodů, sdíleného adresáře, aby nemohlo dojít ke kolizi. Za tímto účelem udržuje přemapovávací "xino" tabulku, což je soubor, jehož velikost vychází z maximální hodnoty inodu - to pochopitelně u tak velikých čísel, jako používá GlusterFS zhavaruje. Vtip je v tom, že v takovém případě to není vůbec zapotřebí. Takže stačí přidat při mountu option "noxino" a overlay funguje jak má.

Unionfs-fuse

Naštěstí se mi podařilo - víceméně náhodou - najít způsob, jak z prekérní situace vybruslit.

Zjistil jsem, že se dá použít unionfs-fuse. Ten sice jede v userspace, což sebou nese degradaci výkonu, ale - a to je důležité - lze nad ním použít modul overlay! Takže pokud adresář sdílený přes NFS překryju nejprve pomocí unionfs-fuse (Ještě jednou díky Radku!) a nad to pak aplikuji overlay, tím dostanu funkční sendvič, který sice data načítá přes userspace, ale změny již honí v jádře.

Možná si kladete otázku: "Nač ta opičárna?" Dostatečné vysvětlení vám snad poskytne následující schéma:

(rychlost I/O operace)
-> pomalá, daná I/O výkonem úložiště
~> relativně rychlá, daná I/O výkonem přes FUSE
=> velmi rychlá, veškeré I/O operace se odehrávají v kernelu

(remote) (userspace) (kernelspace)
NFS      FUSE        OVERLAY
read ->  bridge  ->  bridge -> čtení obsahu
                     write  <= zápis změny
                     read   => čtení změněného souboru

(remote) (userspace)
NFS      FUSE
read ->  bridge  ->  čtení obsahu
         write   <~  zápis změny
         read    ~> čtení změněného souboru

Pokud vás zajímají konkrétní čísla, tak přečtení souboru .tar.xz s archivem souborů linuxového kernelu (tar.xz) - 56573 souborů o celkové velikosti komprimovaného balíku 87MB, trvalo 9.899 sekund (user 9.016s; sys 0.740s). V systému překrytém pouze unionfs-fuse jeho rozbalení trvalo 23.508s (user 9.704s; sys 3.112s), kdežto v systému kde je nad unionfs ještě overlay to trvalo 11.401 sekund (user 9.260; sys 2.136s) - jde o virtuál, který má k dispozici dvě jádra, a NFS poskytuje Ganesha nad replikovaným GlusterFS svazkem. Úzkým hrdlem z hlediska výkonu IO je GlusterFS, ale to je zase jiná pohádka.

Z toho je zřejmé, že tam je nezanedbatelný výkonostní rozdíl, byť je ze systémového hlediska podobný sendvič pěkná čuňačina.

Podobně by mohlo pravděpodobně fungovat i AUFS, pokud bych měl zakompilovanou podporu pro použití FUSE (volba CONFIG_AUFS_BR_FUSE). Bez ní skončí pokus o překrytí unionfs-fuse následující chybou:

[  204.989454] aufs au_xino_create:787:mount[544]: xino doesn't support /tmp/.aufs.xino(fuse)

Jenže...

V předchozím odstavci jsem uvedl, že na to, jak očůrat overlay pomocí unionfs jsem přišel pouhou náhodou. Věc se má totiž tak, že pokud použijete initramfs-tools verze vyšší než 0.120, tak vám spouštění tak jak tak zkolabuje v poslední fázi. Takže nejspíš skončíte takto:

Begin: Running /scripts/init-bottom ... done.
run-init: nuking initramfs contents: Directory not empty
[    6.101871] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[    6.101871]
[    6.104013] CPU: 0 PID: 1 Comm: run-init Not tainted 4.3.0-1-amd64 #1 Debian 4.3.3-5
[    6.104013] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
[    6.104013]  0000000000000000 000000004b049e4b ffffffff812ddce9 ffffffff817f6018
[    6.104013]  ffffffff8115d8fc 0000000000000010 ffff88013ab33ed8 ffff88013ab33e70
[    6.104013]  000000004b049e4b ffffffff8114bec2 0000000000000100 ffff88013ab39b50
[    6.104013] Call Trace:
[    6.104013]  [<ffffffff812ddce9>] ? dump_stack+0x40/0x57
[    6.104013]  [<ffffffff8115d8fc>] ? panic+0xd3/0x20b
[    6.104013]  [<ffffffff8114bec2>] ? task_function_call+0x52/0x80
[    6.104013]  [<ffffffff81075eeb>] ? do_exit+0xb0b/0xb10
[    6.104013]  [<ffffffff811cd550>] ? vfs_write+0x140/0x190
[    6.104013]  [<ffffffff81075f23>] ? SyS_exit+0x13/0x20
[    6.104013]  [<ffffffff81584db2>] ? system_call_fast_compare_end+0xc/0x67
[    6.104013] Kernel Offset: disabled
[    6.104013] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[    6.104013]

Ze spouštěcího init skriptu byla commitem c6d067 ze 17. ledna 2016 odstraněna podmínka, která prioritně používala pro přepnutí do systému switch_root, který je součástí busyboxu. Bohužel run-init (součást balíku klibc-utils ) nad překrytým kořenovým systémem kolabuje a jinou alternativu zatím init skript z initramfs-tools-core od verze 0.122, který je aktuálně v Debianu unstable, nenabízí. Psal jsem sice Benu Hutchingsovi, že jeho commit znefunkčnil jedinou použitelnou alternativu pro překrytí systémového adresáře sdíleného přes NFS, jestli by tedy nepřidal do init skriptu alespoň nějaký parametr, kterým by bylo možné volit preferovanou variantu, ale ten mne požádal, abych pro oznámení problému použil reportbug. Ten se mi ale nejspíš nepodařilo odeslat. Nicméně o problému ví a mne teď čeká týden dovolené, takže uvidím, jestli během té doby nebude do initramfs-tools implementovaná nějaká změna.

       

Komentáře

[Radek Podgorny]

...nemas ty benchmarky nejak prehozene? unionfs+overlay je rychlejsi nez samotny unionfs?

btw, do fuse ted mozna prijde patch pro delegovani read/write operaci, takze unionfs by mohl vyrazne zrychlit.

...jo, a nemas zac. jsem rad, ze to nekomu pomaha.

[Aleš Kapica]

Nemám. Ono to i dává smysl. FUSE je pomalé už z principu. Ten unionfs je pro overlay v podstatě jakési šidítko - nic se do něj neukládá, a data přes něj jenom protékají do kernelspace. Takže sám o sobě pouze zajišťuje něco (nevím co) co overlay očekává od spodní vrstvy. I když nechápu proč by ho to vůbec mělo nějak zajímat když má být čistě transparentní.

Ještě plánuji pokus s kompilací jádra s configem SUSE, podle mých informací má Szeredi vyvíjet overlay nad touto kombinací modulů.

Na každý pád ale vylepšení FUSE bude ku všeobecnému prospěchu.

[Kvakor]

Kdybych potřeboval uchodit souborový systém, který je založený na read-only datech přes síť, ale povoluje lokální zápis, tak za předpokladu, že by NFS by vypadlo ze hry, bych zkusil jít o úroveň níž a použil read-only síťové blokové zařízení (NBD/iSCSI/AoE nebo něco na ten způsob), to přimountoval (logicky) read-only a overlay udělal nad ním. Bylo by zajímavé udělat pro srovnání benchmark, ale podle mých zkušeností je minimálně u velkých asouborů (a tím velkých myslím gigabyty a víc) NBD rychlejší než NFS, což bych typoval na nižší režii protokolu a to, že metadata souborového systému jsou u NBD cachované lokálně.

[Aleš Kapica]

Samozřejmě, že to není jediné řešení, které mám v rukávu. A zrovna přes NBD mám elegantní řešení, které by umožňovalo vzdáleně propagovat i widlácké stroje, a to i bez overlaye. Použil bych xnbd-server v režimu proxy a KVM virtualizaci. Jenže to má zase jiné háčky - integrace do AD, konfigurace aj. Overlay je čistě linuxová záležitost, která má ovšem zase jiné bonusy.

NBD je rychlejší než NFS už z principu, protože je mnohem jednodušší a má tím pádem i menší režii. Jenže není tak blbuvzdorné a má jednu zcela zásadní vadu - neumí se automaticky znovu připojit, po restartu NBD serveru.

iSCSI je v tomto směru na tom lépe, ale pokud se má na jedno blokové zařízení připojovat více strojů, tak se pak tuším musí zase řešit multipath a nemá tu výhodu proxy režimu jako xNBD.

NFS je sice pomalejší, ovšem nepracuje s blokovým zařízením, ale s jednotlivými soubory. Je mnohem pružnější z hlediska použití a když se restartne NFS server, tak se nic neděje. Při použití overlaye funguje poměrně slušně i z infrastruktury na obstarožním hardware.

[Aleš Kapica]

Kromě toho disklessová infrastruktura založená na NFS je velmi robustní - provozujeme ji už nějakým rokem a v porovnání s jinými technologiemi je téměř bezproblémová. Jednoduché zálohování, jednoduchý provoz. Ta stávající měla jediný problém NFS server kolaboval, při mazání většího počtu snapshotů. A na ten už jsem také vyzrál - je třeba nejprve zajistit, aby se subvolume ke kterému se snapshot vztahuje NFS server během té doby nepracoval. Už jsem tady o tom jednou psal.

A když se místo DRBD použijí distribuované storage.. Tak je to úplně v pohodě - no a to je ten důvod, proč vůbec řeším ten overlay - aby bylo možné na nové, aktualizované infrastruktuře uchodit i osvědčená řešení. On se totiž ten overlay sakra hodí, pokud potřebuji otestovat co udělá nějaký vypečený upgrade.

[MartinR]

Zajímavý příspěvek, díky!

Nedávno jsem na něco podobného taky narazil Merge two NFS shares with OverlayFS, pořádně mě to tehdy rozčililo.

Potřeboval jsem spojit dva velké read-only adresáře do jednoho a to by minimálně podle dokumentace mělo jít. ('A read-only overlay of two read-only filesystems may use any filesystem type.')

No a nakonec jsem taky použil union-fs.

[dumblob]

Zkoušel jsi v posledních měsících, zdali již "overlay" v nových jádrech jede nad NFS? Pro jádro 4.4.35 mám stále v manu:

The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide a valid d_type in readdir responses, so NFS is not suitable.

Docela by se mi tato funkcionalita hodila pro vyhození závislosti na FUSE.