mcachefs

Na rozdíl od catfs, mcachefs nechává symlinky symlinkama. Je naprogramovaný v C, menší a podstatně svižnější.

Historie

Původní verzi napsal Michael Still, který o tom napsal 17. března 2004 do mailové konference na samba.org. Jeho původní kód, který ppracoval s první verzí FUSE, co se objevila v jádře jádro 2.x, je k nalezení na webu http://www.gtoal.com/fusestuff . Ale s přechodem na FUSE verze 2 přestal být použitelný.

Opuštěného kódu (verze 0.5.20) se v srpnu 2009 ujal Francois Barre. Přepracoval ho pro FUSE verze 2.7 a umístil do SVN repozitáře, který stále visí na sourceforge.net. Poslední commit r22 do SVN poslal 10. října 2010 a protože během následujícího půl roku nebyla ohlášena žádná chyba, která by vyžadovala změny v kódu, umístil v dubnu 2011 svůj kód verze 0.5.30 na code.google.com.

Až v červnu 2014, kdy se do jádra dostal kód pro FUSE verze 2.9 bylo nutné opět udělat změny v kódu, proto ho z SVN přestěhoval do repozitáře na githubu. Tam visel od října 2017 jeho upravený kód bez dalšího commitu.

Časem bylo vytvořeno z jeho repozitáře několik forků, ale teprve koncem března 2019 se našel vývojář odhodlaný vyřešit známé nedostatky původního kódu – Roberto Hradec. Francois Barre už také některé jeho úpravy do svého repozitáře integroval, ale protože některé problémy, na které jsem rovněž narazil, řeší zatím pouze Robertova vývojová verze, doporučuji používat jeho fork.

V současné době (září 2019) je v jádře FUSE 3.6, ale verze 2.9.9 se kterou pracuje mcachefs je stále podporovaná.

Použití

U disklessového linuxu využíváme mcachefs jako transparentní vrstvu, přes kterou se kopírují soubory z NFS na lokální blokové zařízení, které funguje jako keš. Prakticky se dá ale použít k vytvoření záložní kopie vybraného adresáře, nebo v kombinaci se sdíleným úložištěm pro kešování často používaných souborů.

Následují schéma demonstruje v čem se liší základní sendvič využívající lokální kešování od klasického disklessu, kdy je overlay sestavený přímo nad NFS.

Sendvič s mcachefs

Podkladový adresář, připojený přes NFS, překrývá mcachefs, který používá jako lokální keš buď adresář, nebo Btrfs subvolume na lokálním blokovém zařízení. To celé překrývá overlay, který zabraňuje tomu, aby se lokální změny ukládaly do podkladových vrstev – v tomto případě do lokální keše.

Vrstvy jsou transparentní, takže pokud se kupř. vylistuje adresář, žádné soubory se po síti nepřenáší. Na lokální keš se soubory z NFS ukládají až poté, co se natáhnou do paměti při prvním spuštění aplikace.

Pak už se spouštějí jen o chlup pomaleji, než by tomu bylo, kdyby se lokální keš nepoužívala – zpoždění způsobuje režie kterou má mcachefs, který průběžně kontroluje, zda-li je stažená verze souboru aktuální ve srovnání s tou na NFS serveru.

Kontroluje se pouze stažený soubor. Nenačítá se znova obsah vzdáleného adresáře! Takže pokud na NFS serveru do adresáře, jehož obsah už je v paměti nějaký soubor, tak se objeví až po restartu.

Sendvič bez lokální keše

U sendviče bez lokální keše adresář sdílený přes NFS překrývá rovnou overlay.

Ani v tomto případě se při vylistování adresáře nepřenáší žádné soubory, ale protože overlay komunikuje přímo s NFS je stejná operace mnohem rychlejší, protože odpadá režie, kterou sebou přináší FUSE.

Nejdéle trvá první spuštění aplikace – v podstatě stejně dlouho jakou u sendviče, který používá mcachefs – systém musí počkat, než se aplikace natáhne do paměti. Ovšem opakované načtení už je mnohem rychlejší, protože ji overlay rovnou natahuje z pamětu a už neposílá žádný dotaz směrem k NFS serveru.

Zásadní rozdíl je ale po restartu. V obou případech se při rebootu zahodí celý obsah RAM, tedy nejenom uživatelské změny, které overlay ukládal do tmpfs ale i natažené soubory.

U sendiče, který využívá jako keš lokální blokové zařízení, se pouze ověří (porovnáním časového razítka a délky uloženého souboru s tím co je na NFS serveru), že jde o jeden a ten samý soubor a pak už se do paměti netahají data po síti, ale rovnou z lokálního blokového zařízení. Kdežto u sendviče, který lokálně uložená data nemá, se natahuje všechno znova.

Pokud máte spolehlivou a rychlou síť, s vysokou propustností, je lokální kešování zbytečné – režie s tím spojená by jenom zdržovala komunikaci s NFS serverem. Ale pokud máte nespolehlivé připojení, jako je kupř. v situaci, kdy se používá disklessový linux přes Wi-Fi, je to výhodné. Bez toho by totiž po každém restartu následovalo martyrium spojené s nekonečným stahováním dat, které by totálně ucpalo provoz na vašem AP.

Lokální kešování přes FUSE do RAM lze využít i v situaci, kdy máte relativně hodně RAM, ale pomalé disky na NFS serveru. Nebo pokud chcete redistribuovat data z NFS serveru dál – NFS totiž za normálních okolností neumožňuje vyexportovat adresář, který je namountovaný z jiného NFS.

Pokud chcete redistribuovat NFS adresář dál, ale nemáte zároveň dost paměti, aby se vám do ní věechny soubory vešly, můžete místo mcachefs zkusit použít [fuse_xattrs] a vyexportovat data skrze něj.

Připojení

Nápověda se zobrazí, pokud spustíme mcachefs bez parametrů. V minimální konfiguraci (kdy se použijí výchozí hodnoty volitelných parametrů) jej můžeme použít takto:

mcachefs /zdroj /cil

/zdroj

Je přípojný bod, na který je namountované blokové zařízení, vzdálený adresář (přes CIFS, NFS, atp.), ale i lokální adresář jehož adresářová struktura poslouží jako podkladová vrstva.

/zdroj

Je přípojný bod (adresář), na který se namoutuje překrytá adresářová struktura.

Odpojení můžete udělat klasicky

umount /cil

nebo přes

fusermount

Výchozí hodnoty, které se použily v tomto minimalistickém případě, můžete při spuštění přenastavit pomocí následujících voleb:

cache

Adresář Default /tmp/mcachefs/root_cil/cache

metafile

Soubor Default /tmp/mcachefs/root_cil/metafile

journal

Default /tmp/mcachefs/root_cil/journal

Není-li řešeno jinak, pracuje mcachefs vždy pouze s jedním vláknem, protože výchozí volba pro parametry je 0

backup-thread

MCACHEFS_TRANSFER_TYPE_BACKUP ovlivňuje počet vláken pro zápis

write-threads

MCACHEFS_TRANSFER_TYPE_WRITEBACK ovlivňuje počet vláken, co zapisují soubory do keše

metadata-threads

MCACHEFS_TRANSFER_TYPE_METADATA ovlivňuje počet vláken zpracovávajících metadata

Následující parametry umožňují navěsit na proces spouštění externích skriptů.

pre-mount-cmd

Default <none>

pre-umount-cmd

Default <none>

Pokud není namountovaný adresář /tmp na tmpfs (který je v RAM), tak se vytvoří /tmp/mcachefs jako normální adresář - takže se bude zapisovat normálně na disk, což pochopitelně může mít vliv.

Jak pracuje s keší?

Po namountování se v rámci přípojeného bodu vytvoří skrytý adresář .mcachefs, který obsahuje následující soubory:

• action - Řídící soubor, který obsahuje následujcí seznam akceptovaných akcí. Pokud zrovna některá z nich neprobíhá, vypadá jeho obsah takto:

[none] apply_journal flush_metadata cleanup_cache fill_cache_meta

• none : Informuje, že aktuálně neprobíhá žádná akce.
• apply_journal : Informuje o tom, že se zrovna aplikují změny, které byly provedené v rámci cíle (a uložené do souborů v keši) na soubory ve zdrojovém adresáři. Jaké změny jsou ve frontě lze zjistit ze souboru journal. Tuto akci lze vyvolat tím, že se do souboru action zapíše řetězec apply_journal
• flush_metadata : Tuto akci lze vyvolat tím, že se do souboru action zapíše řetězec flush_metadata
• cleanup_cache :
• fill_cache_meta :

• cache_prefix - Obsahuje /
• file_thread_interval - Obsahuje 1
• file_ttl - Obsahuje 300
• journal - Fronta úloh, čekajících na akci apply_journal. Ve výchozím stavu je tento soubor prázdný, dokud nedojde v rámci cílového adresáře k editaci, či smazání souboru.
• metadata - Obsahuje aktuální strom metadat, interpretovaných z obsahu binárního metadatového souboru, do kterého se načítají data při prvním načtení adresáře. Pro aktualizaci změn provedených na úrovni zdroje, se musí zavolat akce flush_metadata.
• metadata_map_ttl - Obsahuje 10
• read_state - Signalizuje aktuální stav pro čtení ze zdroje. Je-li vše OK vypadá jeho obsah takto:

[normal] full handsup nocache quitting

• normal : Signalizuje normální stav. Pokud soubor, se kterým chceme pracovat v keši není, tak se do ní nakopíruje a veškeré změny provedené na úrovni cílové vrstvy se zapíšou do něj.
• full : Signalizuje, že je plná keš. Nové soubory se do paměti budou načítat rovnou ze zdrojového adresáře, ale nebudou se kopírovat do keše. A nebude možné uložit změny, souborů otevřených z cílového adresáře.
• handsup : Signalizuje, že obsah zdrojového adresáře není nedostupný
• nocache : Signalizuje, že se keš nepoužívá? Nevím.
• quitting : Signalizuje, že se mcachefs připravuje na vypnutí a postupně uzavírá všechny oteřené soubory.

• timeslices
• transfer
• transfer_max_rate - Obsahuje 100000
• write_state - Signalizuje, jakým způsobem se zrovna mcachefs chová při zápisu. Je-li vše OK vypadá jeho obsah takto

[cache] flush force

• cache : změny se zapisují do souborů v keši a do fronty v souboru journal se řadí změny, které čekají na zápis zpátky do zdroje.
• flush : změny z keše se aktuálně zapisují do zdrojového adresáře
• force : do keše nelze zapisovat, je plná!

Řízení mcachefs se provádí zápisem klíčového slova do řídících souborů. Aktuální stav vždy odpovídá klíčovému slovu v hranatých závorkách.

Dokud se pracuje pouze s adresářovou strukturou, tak se do keše nekopíruje nic. Soubor se do ní uloží teprve v okamžiku, kdy ho otevřete pro čtení.

Pokud se obsah zdrojové vrstvy v průběhu připojení změní, tak se změna do cílové vrstvy nepromítne! – až po remountu.

Na co si dát pozor

Faktem je, že některé věci autor mcachefs nedomyslel.

Problematická práce s metadaty

Aktuálně mcachefs udržuje metadata v rámci jednoho binárního souboru, a nemá podporu pro atomické změny.

Tak jak se volají soubory, načítají se postupně i metadata. Ovšem jsou-li jednou načteny, existuje pouze jediný způsob jak je aktualizovat – odeslat řetězec 'metadata_flush' do souboru .mcachefs/actions

Na základě této operace mcachefs obsah souboru pro metadata zahodí a začne je načítat znovu. Ovšem pokud nám jede z mcachefs systém, nastane problém, protože se tím "ustřelí" již načtené knihovny.

Správné řešení problému by představovala atomická změna. Jenže pak by bylo nutné ošetřit jiným, než stávajícím, způsobem symlinky a adresáře.

Paralelizace načítání souborů

Problematická práce s metadaty je rovněž příčinou kolapsů při paralelním načítání souborů.

Pokud se načítají soubory postupně, nic se neděje, ale v okamžiku kdy jiný proces sáhne na soubor, který se teprve natahuje, vzniká problém – chybí semafory.

Pokud by nový proces zjistil, že se na soubor čeká a vyčkal s kontrolou, než se předchozí proces dokončí, tak by problém nevznikl. Jenže nic takového k dispozici není, takže to skončí kolapsem.

Neošetřené symlinky

Nekontrolují se metadata symlinků. Jenže neaktualizovaný symlink může rovněž vést ke kolapsu systému.