Linux.com představuje compFUSEd (diskuse)

[sudcadred]

nieco ako stacker? ci ako sa volal ten program za cias DOSu?

[pc2005]

Jo stacker ten byl dobrej, jen se s ním disk defragmentoval tak 2 - 3 hodiny. Pak byl taky "vypůjčenej" microsoftí doublespace/drivespace.

[Luk]

doublespace

Přezdívaný DoubleTrouble Jednou se mi sekl (kvůli přehřátí) procesor uprostřed zápisu na takový disk. Ta paseka, jakou to vyrobilo ve filesystému, stála opravdu za to...

[pc2005]

Nejlepší byl na tom způsob zavádění driveru, to se pak člověk modlil, aby to nabootovalo.

[andree]

tyvole, ale mohli si aspon hlavicku na tej homesite zmenit

[David Watzke]

Indeed

[Vin]

Brr, Joomla.

[m1c4a1]

Nijak víc se o to nezajímám, ale neví někdo, jak je to s vytížeností stroje, když to furt něco komprimuje a dekomprimuje?

[Xerces]

Tak asi to něco žere ale když vám jde o kapacitu tak k čertu s tím, ne vždy je rychlost primárním aspektem. Něco takovýho pod Linux už dlouho hledám.

[Aleš Janda]

+1 já taky.

On vůbec na Linuxu chybí FS s transparentní kompresí. Existuje akorát Reiser4, který není příliš podporovaný (a doporučovaný) a pak ZFS, který má licenční problémy a podporovaný není už vůbec.

Ale zajímalo by mě, jestli to zabaluje po blocích nebo celý soubor. Co když třeba čtu zprostředka gigového souboru? Nebo co když někam doprostřed chci nedejbože něco zapsat? A jak je to, když chci něco přidat na konec (logy)?

[Milan]

No, taky si prihreju polivcicku: miio.net/fusecompress

[Aleš Janda]

Joj, to vypadá velice lákavě

Mohl bys to nějak srovnat s popisovaným řešením? Doporučil bys to svoje řešení? Používá se někde?

Pracuje to na úrovni souborů nebo úrovni FS? A hlavně by mě zajímalo: pokud by se něco podělalo a já ten disk odnesl k úplně jinému počítači bez ničeho, budu schopen z toho dostat ta data?

Omlouvám se za tolik otázek Díky.

[Milan]

To popisovane reseni neznam No, to svoje reseni bych samozrejme doporucil , ale to je strasne neobjektivni doporuceni

Sem tam mi prijde mail od lidi kteri to pouzivaji, nejcasteji spolu s rdiff-backup pro zalohovani.

Pracuje to na urovni souboru, takze to vyuziva jiz existujici filesystem. Zjistuje jestli soubory jsou uz komprimovany a pokud ano tak je znovu nekomprimuje a nechava je tak jak jsou.

No, podelat se to muze nekolika ruznymi zpusoby Ale neni problem to prekopirovat na jiny pocitac a data dekomprimovat i bez pouziti fuse. Melo by to byt bezpecny i co se tyce endianovosti a 32 vs 64 bit systemech.

Proste to vyzkousej (pouzij svn verzi) a uvidis jestli ti to za to bude stat. Je to otazka maximalne pulhodinky...

[Aleš Janda]

Díky, rozhodně to vyzkouším. A když se osvědčí, tak i reálně nasadím.

Ještě poslední otázka: když je to na úrovni souborů, jak ta vrstva rozliší, jestli ten soubor na disku už je nebo není zabalený? To přece z obsahu nepozná, tam může být cokoli...

Jinak jsem našel toto docela zajímavé srovnání: http://fuse.sourceforge.net/wiki/index.php/CompressedFileSystems

[Milan]

Z obsahu se to pozna. Viz file (1) a libmagic.

[dik]

cau,rad bych se te zeptal ,jak je tvoje stabilni ,pripadne se chova v nestandartnich situacich ? Jak pises ,ve spojeni s rdiff-backup nebo rsnapshot je idealni. Mam zalohovaci pole o kapacite cca 5T ,kde by se mi online komprese na zalohy hodila ,ale mam z toho troska strach. Pekny projekt a mej se , dik

[Milan]

Jasne, taky bych mel strach. Co se tyce stability: Nevim o problemech pri pouzivani rdiff-backup. Vim o problemu pri pouzivani postgressu na multiprocesorovy masine. No, chovani pri nestandartnich situacich je takovy ze fusecompress bud spadne, nebo dostanes spatny data ze souboru. Fusecompress pracuje na kazdym souboru zvlast, takze chyba by nemela ohrozit ostatni soubory se kteryma nebylo pracovano.

[Aleš Janda]

Tak jsem to vyzkoušel. Překopíroval jsem /usr/bin do komprimovaného adresáře. Všechno ok, rychlost tak o 0 - 50 % nižší, podle toho, co se s tím dělá. (Nejhorší je zápis nekomprimovatelného souboru, např. filmu.)

Přišel jsem na tři bugy (vlastnosti?):

• program si nějak špatně poradí (asi) se symbolickými odkazy. Při pokusu o smazání toho nového /usr/bin se to fusecompress nějak zvláštně kousne a s ním i půlka systému. Není to u všech, nevím, co přesně to dělá
• při pokusu o dekompresi pomocí fuscompress_offline to vyhodí SIGSERV
• pokud adresář přimountuju jako root, nedostane se do něj běžný uživatel. Pokud ho přimountuju jako běžný uživatel, nedostane se do něj root (wtf? )

Ještě to otestuju.

[Milan]

Pouzivas svn verzi? Kouknu na problemy 1 a 2, ale 3 je vlastnost fuse. Pomoci parametru prikazoveho radku lze fuse nastavit tak aby se do adresare root dostal.

[Aleš Janda]

Ano, používám SVN verzi, včera staženou S tím rootem jsem to nevěděl, ok.

I tak se mi ten prográmek ale hodně líbí. Kdybys potřeboval nějaké další informace nebo simulace chyby, nějaké kontakty mám v profilu

[vadimo]

Ked som instaloval Slax Frodo na cca 100MB disk a nechcel sa mi ta nejak natesnat , tak som pouzil program upx. Ten zas komprimoval binarky. Vsetko fungovalo az do doby, pokial som neskomprimoval "nieco" ale uz neviem co to bolo a Slax ostal KO Bolo to v mojich linuxovych zaciatkoch. Akože UPX je u mňa dobrý program a preto si ho aj pamätám.

[Luk]

Raději bych to viděl přímo v kernelu. Už samotná komprese žere dost výkonu, a když se ještě přidá režie FUSE, to už pak bude pořádná želva.

[Milan]

No, jak rikas, komprese zere dost vykonu, takze fuse rezie je potom zanedbatelna. Problem je u tech operaci ktere nezerou dost vykonu (jako fstat/lstat) u tech je to zpomaleni videt...

[Luk]

komprese zere dost vykonu, takze fuse rezie je potom zanedbatelna

Ona až tak zanedbatelná není. Jednak záleží, jak je to implementované (neviděl jsem zdrojáky, nemohu se vyjadřovat), a dále také, jaký kompresní algoritmus se použije - pokud deflate, ten tak žravý není a režie FUSE bude znát.

Problem je u tech operaci ktere nezerou dost vykonu (jako fstat/lstat) u tech je to zpomaleni videt...

Tohle je obecný problém FUSE. Ona tedy, upřímně řečeno, kernelová implementace fstat/lstat také není kdovíjak úsporná (trojité kopírování). Ale všechny filesystémy, které se budou používat intenzivněji (ne pouze příležitostně), patří podle mého názoru přímo do jádra.