Hlavní navigace

LUFS - tak trochu jiný virtuální souborový systém

Michal Krause

Nedávno jsem se ve Sklizni zmiňoval o projektu LUFS, který umožňuje univerzálním způsobem vytvářet virtuální souborové systémy a zpřístupnit je zcela transparentně libovolné aplikaci. Dnes se mu podíváme na zoubek detailněji.

Úvod, aneb trocha teorie nikoho nezabije

Úvodem si řekneme něco o principu fungování projektu LUFS. Již v citované Sklizni jsem nakousl problematiku implementace virtuálních souborových systémů (dále jen VFS). Představme si, že třeba chceme zpřístupnit obsah FTP serveru jako kdyby to byl lokální souborový systém. Základní přístupy k implementaci jsou dva: buďto využijeme mechanismů, který nabízí jádro operačního systému, a nebo přeneseme celou správu takového VFS do aplikačního prostoru. Obě tato řešení jsou technicky možná, ale obě mají svá pro i proti.

Využijeme-li možností jádra, největší a zásadní výhodou bude naprostá transparentnost pro všechny aplikace. Nebude záležet na tom, co je váš oblíbený správce souborů, komprimační program nebo třeba přehrávač multimédií – všechny budou schopné pracovat se soubory na vzdáleném FTP serveru, protože celý protokol obalí jádro svými vlastními systémovými voláními, která jsou na konkrétním typu souborového systému (dále jen FS) nezávislá. Tento obrovský klad je ale vykoupen téměř stejně důležitými zápory. Mezi ně patří zejména složitější programování v jádře oproti aplikačnímu prostoru a v neposlední řadě také nebezpečné proplétání aplikačních a systémových záležitostí. Osobně jsem zastáncem názoru, že třeba implementace věcí, jako je FTP protokol, do jádra prostě nepatří.

Druhým obecným přístupem k programování VFS je kompletní implementace v rámci aplikačních prostoru. Typickým příkladem může být například KIO v KDE, které umožňuje aplikacím pracovat s VFS pomocí URL, jak je známe z webu. V tomto systému je každý typ FS určen „protokolem“, podle nějž se rozhodne, který „ovladač“ se použije k zprostředkování přístupu k souboru. Jak vidno, toto řešení obchází nutnost implementovat aplikační protokoly do jádra, což je pozitivní, leč zase vyvstává jiný problém: bude to celé fungovat jenom pro aplikace, které s podobným systémem počítají. Budeme-li se držet příkladu s KDE, pouze aplikace používající pro práci se soubory rutiny z KDE knihoven budou ze systému KIO profitovat. To je ovšem poměrně zásadní omezení pro kohokoliv, kdo nepracuje v přísně homogenním prostředí, což upřímně řečeno není asi nikdo.

Po tomto obšírném úvodu se dostáváme konečně k principu, na němž je založen LUFS. Bystrý čtenář již jistě pochopil, že existuje přístup třetí, takzvaný hybridní, který se snaží spojit výhody a eliminovat nedostatky obojího. Jádro potřebujeme proto, aby VFS byl transparentně přístupný pro všechny aplikace bez rozdílu (dalším možným řešením by bylo podstrčení upravených IO funkcí pomocí speciální knihovny, ale tento přístup by neměl žádný vliv na staticky linkované aplikace), takže LUFS implementuje jaderný modul, nicméně jeho cílem je pouze zpřístupnit FS vytvořený v aplikačním prostoru zvláštním démonem. Obě komponenty spolu pak komunikují přes unixový socket. Tento přístup skutečně bere z jaderného i aplikačního řešení to nejlepší, ale ideální řešení pochopitelně neexistují, takže je třeba říci, že i on má své mínusy, a to zejména větší režii v komunikaci mezi modulem a démonem. Naštěstí bývá nejčastějším důvodem implementace VFS tohoto typu zpřístupnění vzdálených síťových služeb, kde limitujícím faktorem bude spíše rychlost sítě, takže to tolik nevadí.

Nyní se ale už pojďme podívat na instalaci a použití LUFSu.

Instalace

LUFS je šířen pouze v podobě zdrojových kódů, takže je třeba jej vždy zkompilovat, což je ostatně dané i potřebou přizpůsobení používanému jádru. Kompilace a instalace je prováděna pomocí klasické kombinace

make
make install

Jediným úskalím, s nímž jsem se při kompilaci na Red Hat Linuxu 7.2 setkal, byla nutnost mít nainstalované zdrojové kódy jádra, neboť hlavičkové soubory v /usr/include z balíčku kernel-headers obsahují makra znemožňující zkompilovat proti nim jaderný modul (přiznám se, že mi není známo, zda je to věc obecná nebo specifická pro Red Hat; v každém případě kompilace počítá s přítomností hlavičkových souborů v adresáři /lib/modules/ uname -r/build/include).

Jistým záporem se mi jeví být absence informací o minimálních požadavcích na verze jádra a kompilátoru v dokumentaci. Takto vám nezbývá nic jiného, než prostě LUFS stáhnout a zkusit, jestli na vaší konfiguraci bude fungovat.

Moduly FS

Při popisu principu fungování LUFSu jsem nezmínil jednu zásadní věc: démon existuje jenom jeden, zatímco jednotlivé FS implementují speciální moduly (staticky linkované v době kompilace). To umožňuje poměrně snadno rozšiřovat nabídku podporovaných FS, a to i vývojářům třetích stran. Momentálně jsou součástí LUFSu moduly localfs (zpřístupnění lokálního souborového systému skrz LUFS – tento modul je zamýšlen jako vzorový pro vývojáře), ftpfs (zpřístupnění vzdáleného FTP serveru) a sshfs (zpřístupnění vzdáleného SSH serveru pomocí nadstavby sftp).

Použití

Použití LUFSu je nadmíru jednoduché – po instalaci se automaticky zavede jaderný modul a spustí démon (nestane-li se tak, můžete to udělat ručně, dokumentace na tento případ myslí) a pak už jen stačí obyčejným příkazem mount připojit požadovaný FS do vybraného adresáře. Například příkaz, který připojí do adresáře ./linux.cz FTP server ftp.linux.cz vypadá takto:

mount -t lufs none ./linux.cz -o \
    nosuid,fs=ftpfs,host=ftp.linux.cz

Na příkazové řádce můžete pomocí další voleb ještě určit přihlašovací jméno a heslo, případně zapnout aktivní režim FTP.

O něco málo složitější je to v případě použití sshfs, neboť pro něj je nutné nakonfigurovat ssh připojení tak, aby používalo RSA autentizaci bez hesla. Součástí distribuce LUFSu je i skript lufs_sshconfig, který vám dokáže vše potřebné nastavit sám, takže pokud se na to necítíte nebo máte s RSA autentizací nějaké problémy, můžete jej zkusit. Vlastní připojení vzdáleného systému je pak jednoduché:

mount -t lufs none ./ssh_server -o \
    nosuid,fs=sshfs,host=ssh.nekde.cz,username=uzivatel

Funkčnost a stabilita

Při relativně krátkodobém (a je třeba říci, že nepříliš sofistikovaném) testování jsem se párkrát dostal do situace, kdy se odezva programu pracujícího se vzdáleným FTP serverem (mc) radikálně zhoršila a pomohlo jenom opuštění připojeného FS. Domnívám se, že k tomu dojde v okamžiku, kdy FTP server ukončí spojení při nečinnosti a démon se s ním stále snaží komunikovat. Nějaké obnovení spojení se bohužel nekoná. Procházení některých adresářů v mc se mi zdálo celkové poněkud pomalé, ale nevím, zda to způsobuje nějaká chyba nebo prostě to, že si mc zjišťuje informace o adresářích a souborech. Dobré je, že se jaderný modul a potažmo běžící aplikace bez problémů vyrovnali se simulovanou havárií démona.

Závěr

LUFS je dle mého názoru opravdu velmi zajímavá implementace VFS, která stojí za pozornost. V současné době se zdá být až na některé mušky poměrně stabilní a pokud v budoucnu přibydou další plánované FS, jako například webdavfs, httpfs nebo freenetfs či nutellafs, bude to jistě velmi zajímavý nástroj pro různé úkoly.

Našli jste v článku chybu?

27. 8. 2002 11:13

JaRo (neregistrovaný)

>Nicméně největší nevýhodu LUFS spatřuji v pomalosti.
>Protože sedim (jako žába) u zdroje, stahuju z např.
>ftp.linux.cz kolem 1,34MB/s ani nemrknu. pomocí LUFS to
>bylo 28,3 kB/s.

Testoval jsem na starém Pentiu 150 s 10Mbit síťovkou. Stahoval jsem velký soubor. Začlo to taky na 30KB/s a pak stale rostlo. Přestal jsem stahovat u 450KB/s. Pak jsem LUFS rozšířil o podporu Novell Netware FTP serveru (a zaslal úpravy autorovi) a připojil se k lokálnímu Novell serveru. A hle 900KB/s…




18. 8. 2002 20:52

Pavel Machek (neregistrovaný)

Zajimave... dalsi implementace filesystemu do userlandu.
Ma jeden problem -- potrebuje modul do jadra. A pravdepodobne ma druhy problem -- nejspis se deadlockne pri extremnim nedostatku pameti.

uservfs je uz docela stara hracka, ktera pouziva existujici coda modul v kernelu (takze zadne kernelove patche) a deadlocky ji nehrozi...

Pavel






Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Podnikatel.cz: Změny v cestovních náhradách 2017

Změny v cestovních náhradách 2017

120na80.cz: 5 nejčastějších mýtů o kondomech

5 nejčastějších mýtů o kondomech

DigiZone.cz: TV Philips a Android verze 6.0

TV Philips a Android verze 6.0

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Vitalia.cz: Když přijdete o oko, přijdete na rok o řidičák

Když přijdete o oko, přijdete na rok o řidičák

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Měšec.cz: mBank cenzuruje, zrušila mFórum

mBank cenzuruje, zrušila mFórum

Vitalia.cz: Pamlsková vyhláška bude platit jen na základkách

Pamlsková vyhláška bude platit jen na základkách

Podnikatel.cz: Snížení DPH na 15 % se netýká všech

Snížení DPH na 15 % se netýká všech

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

120na80.cz: Na ucho teplý, nebo studený obklad?

Na ucho teplý, nebo studený obklad?

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky