lzap: lzop je super!

5.9.2005 10:26 | Přečteno: 1705× | Linux

Můj nick je lzap. Já, lzap, objevil lzop. Program lzop komprimuje. Já nikoli. Tímto bych rád předešel dalším diskuzím: já nekomprimuji. A rychle už vůbec ne.

Utilitka lzop je ale pekelně rychlá - koprimuje 3-5x rychleji, než gzip -1, ovšem dosahuje o asi 10-15% nižšího komprimačního poměru. V časopise Linux FORMAT vyšel bezvadný článek na toto téma, a já se jal program lzop prozkoumávat: emerge lzo lzop.

Když jsem proniknul do tajů knihovny lzo, zjistil jsem, že se jedná o blokový komprimační program, který napsal autor programu UPX - také docela rychlého a hodně, hodně moc přenositelného komprimátoru binárek. Docela mě to zaujalo a pokusil jsem se neúspěšně najít nějaký souborový systém, který by on-line komprimoval.

Některé mé adresáře (nesnáším "složky", zní to jak "vložky") obsahují totiž velmi mnoho textových souborů. Takový komprimovaný filesystém by se hodil. Určitě nějaký existuje (diskutujte!), ale myslím, že žádný z nich nebude podporovat lzo.

Jeden podvečer jsem věnoval kódování v jazyce C (velmi dlouho jsem vzpomínal na dereference pointerů a jiné záležitosti, které jsou mi u Javy cizí). Kromě toho, že jsem zjistil, že plugin Eclipse-CDT je úplně super a vůbec se nemusím nořit do tajů programů Autoconf/Automake, jsem musel konstatovat, že pomocí FUSE (Filesystem In Userspace) takovou utilitku asi nenapíšu.

Problém je ten, že FUSE funguje příliš nizkoúrovňově - implementuje funkce open, read a write. Ačkoli by nebyl problém vytvořit si vlastní cache pro čtení (blokový algoritmus lzo to navíc velmi usnadňuje) a pohlídat si vlákna, zápis by byl velmi neefektivní. Navíc, velikost komprimačních bloků by nebyla vždy stejná, jako bloky, kterými čte program a každý přístup bych musel "odskočit" na začátek souboru a zjist velikost bloku a zda je vůbec lzopem komprimován.

Aby to nebyl zas tak "neúspěšný" zápis, rozhodl jsem se alespoň publikovat svůj zálohovací příkaz. Se lzopem je zase o něco rychlejší:

tar --use-compress-program=lzop -cv ~ /etc | \
mkisofs -stream-media-size 333000 | \
cdrecord dev=/dev/hdc -fs=32m -dao tsize=333000s -

Existuje vůbec FS s podporou komprimace? Používáte komprimované adresáře? A vůbec, kolik sekund má 700MB CD?

       

Komentáře

[Mikos]

A co prostě použít SquashFS? Nevím sice jaký používá kompresní algoritmus, ale je dělaný tak aby měl dobrý kompresní poměr a byl přitom i velmi rychlý. Používají ho prakticky všechny moderní LiveCD distribuce. Tak si buď udělat malou samostatnou partition a na ní mksquashfs, nebo prostě velký soubor ve tvém současném filesystemu, který budeš mountovat přes loop a uděláš na něm mksquashfs.

Ale není to pravda moc flexibilní řešení. FUSE by bylo na to co chceš ty lepší Pokud bys tedy ten filesystem do FUSE udělal tak, aby mohla jeho velikost růst s tím jak do něj budeš věci kopírovat (prostě abys nemusel mít na disku soubor jedné pevně dané velikosti mountovaný přes loop, ale soubor který by se dynamicky zvětšoval/zmenšoval podle toho co by v něm bylo). Podobně co sem tak četl pod FUSE funguje EncFS. Tak na něj kdyžtak koukni, jak tam je to řešeno A pokud chceš použít lzo kompresi, doporučuji využívat přímo onu knihovnu a né lzop utilitu.

[Lukáš Zapletal]

Na SquashFS jsem se samozřejmě díval. Nutný patch, a používá to pomalejší gzip.

Já už jsem kus práce udělal za těch pár hodin, mám to navrženo tak, že po připojení se to jen "přemapuje" do adresáře /var/lib/lzofs s tím, že se soubory mají komprimovat. Při implementaci toho komprimování jsem se práve zasek.

EncFS to má jednoduchý - soubory jsou stejně velké, takže i seeky jsou stejné. U komprese nikoliv.

Přirozeně, že používám liblzo, co jiného taky

[Lukáš Zapletal]

Nutný patch do kernelu... (a ta čárka tam nemá být).

Napadlo mě, že bych to udělal tak, že po přimountování by to prošlo celý adresář /var/lib/lzofs a nezkomprimované soubory by to zkomprimovalo. Připojený FS by pak byl pouze pro čtení (adresáře a linky by však vytvářet šly stejně tak jako mazání - prostě jen WRITE by zahlásil DISK FULL nebo něco podobného).

[Mikos]

Aha, mě nějak z téhle věty: "a každý přístup bych musel "odskočit" na začátek souboru a zjist velikost bloku a zda je vůbec lzopem komprimován." přišlo, že chcete používat nějak onu utilitu lzop, ne přímo knihovnu lzo2

Jinak SquashFS snad bude někdy přijatý přímo do oficiálního kernelu, vím že nějaké diskuze o jeho začlenění na LKML proběhly, jak to s tím ale v současnosti konkrétně vypadá netuším... co se týče jeho rychlosti, tak sem četl že je o dost rychlejší než třeba gzip komprimované ISO (pomocí mkzisofs), takže sem předpokládal že používá asi nějakou jinou kompresi než gzip. Ale možná je ta jeho rychlsotí výhoda v něčem jiném...

Ohledně té vaší poznámky k EncFS - znamená to tedy, že tenhle váš LZO userspace filesystem nebude umožňovat onu dynamickou velikost souboru v kterém je uložen? Je to principiálně nemožné nebo jen moc složité na implementaci?

[Lukáš Zapletal]

Knihovna není lzo2 ale lzo, lzo2 je něco jiného (jiný projekt). Odzkkočit na začátek si musím vždy, jednak zjistit, zda je soubor komprimován (magic file handler) a zejména načíst velikost komprimačního bloku. Ono to lze ošetřit taky u funkce open/close, pak ale budu muset trošku postudovat LTHREADS, protože to musí být vláknově zabezpečené (musel bych vytvořit globální pole handlerů).

Můj lzofs není uložen v jednom souboru, to je zbytečné. Chci ho používat ke kompresi adresářů, ve kterých jsou miliony malých textových souborů - tím bych úplně odstavil svůj rychlý XFS. Jak jsem naznačil, všechny soubory jsou uloženy jako obyčejné soubory ve /var/lib/lzofs, jenom jsou (budou) komprimovány.

Jsem hodně zvědav na rychlostní testy, lzo je při čtení někdy i rychlejší, než nezkomprimovaný soubor. To ale bude platit zřejmě jen u sekvenčním čtení velkých souborů.

Jelikož něco podobného chybí (existuje pouze projekt fuse-j-zip - javovský binding na FUSE s examplem "read only filesystem in ZIP"), asi to dotáhnu do konce.

[Mikos]

Může to být dobrý projekt, držím vám palce

Co se týče toho ukládání souborů ve /var/lib/lzo - na tom se mi nelíbí to, že je to system-wide adresář. To opravdu není moc dobré řešení, jak z bezpečnostního hlediska tak z hlediska možné přenositelnosti souborů. Ty zkomprimované soubory by se určitě měly ukládat v uživatelově domovském adresáři. Např. tak, že by zadal 'lzofsmount /home/mikos/dokumenty' a ono by to onen adresář dokumenty zkomprimovalo (všechny jednotlivé nezkomprimované soubory v něm) a každý nový soubor který bys tam vytvoři/nakopíroval v době, kdy je to přimountované, by byl transparentně komprimován (a samozřejmě pak i zpětně dekomprimován).

Btw. v čem je to LZO verze 2 jiný projekt? Já koukal na domovské stránky autora LZO a tam je právě ke stažení už ta verze 2.01, stará verze 1 je tam ještě v adresáři LZO-v1. Z toho sem pochopil že LZO 2 je zjevně mnohem novější a lepší než LZO 1, ale tu verzi 1 tam nechal z důvodu že je to zpětně nekompatibilní či tak něco. Ale jsou to jen mé spekulace, nějak sem se tomu že bych to prostudoval moc nevěnoval, tak mě kdyžtak opravte

[Lukáš Zapletal]

Aha, špatně jsem hledal, vygooglil jsem nějaký SSH-LZO2 projekt. Myslel jsem, že je to něco jiného. Ano, používám verzi 2.01, ovšem na mém Gentoo systému je to liblzo (balíček lzo). Žádná dvojka.

S tím domovským adresářem je to jasné, taky jsem o tom přemýšlel, ale narazil jsem na omezení FUSE - ještě jsem nepřišel na to, jak předat vytvářenému filesystému parametr. On se totiž "mountuje" tak, že se spustí user-program. Zkusím to nějakým parametrem, který nebude narušovat FUSE, případně to zadrátuji na "~/.lzofs" (symlinkem si to může každý dát na jiný disk - já osobně bych něchtěl v houmu věci, které se nemají zálohovat).

Díky za informace, určitě na to večer mkrnu a poreferuji

[msk]

V konecnom dosledku mate pravdu, len by som doplnil, ze encfs neuklada do vlastneho fs, ktory ma namountovany ako loop, ale priamo zapisuje subory a adresare na disk, ako akekolvek ine subory. Takze problemy s resize odpadnu nadobro.