Vlákno názorů k článku Reiser4: Mrtvý souborový systém? od Tomáš Raček - Ještě by možná nebylo špatné uvést, kolik na...
-
Článek je starý, nové názory již nelze přidávat.
-
Tomáš Raček (neregistrovaný)Patchnul jsem gentoo-sources, ale asi v tom nebude rozdíl. Patch pro 2.6.25 naleznete tady.
-
Uživatelce zkrouhli nick (neregistrovaný)Bohužel jsem asi debil, ale nezdařilo se mi stáhnout zdroje pro gentoo, takže mám jen Vanillu, 2.6.25.9. +-megabajt by to srovnatelné být mělo.
Čistá velikost dat je 253MB, velikost udávaná windowsama jako "velikost na disku" je 307MB, volné msíto po rozbalení kleslo z 830 na 509MB.
Vinu na této nesrovnalosti přikládám (hypotéza) tomu, že jede o silně zaplněný a fragmentovaný disk (hodně gigabajtových souborů, které už nikdo jen tak nezkompletuje) a zřejmě bylo třeba vytvořit nový fragment MFT, jelikož zdrojáky mají 25K souborů...
Po aplikaci NTFS komprese na složku se zdrojáky je obsazené místo hlášené systémem 177MB a volné místo hlášené systémem 638MB (z původních 830). Poznámka: Rozdíl je tedy opět asi 15MB, zřejmě způsoben nárůstem MFT.
Srovnání s linuxovými FS, dle Tomáše Račka výše, (díky):
Ext3: 317MB
Reiser4 269MB
NTFS: 307/321MB
Reiser4, transparentní komprese složky: 195MB
NTFS, transparentní komprese složky: 177/192MB
Komentář: NTFS je v základu zdá se na úrovni nebo horší než ext3, nicméně nevím, jestli v případě ext3 také nekleslo volné místo nad rámec místa použitého pro data vlivem metafat (jako u NTFS o 15MB). Čili je třeb brát s rezervou, přikláněl bych se k hodnocení "srovnatelný".
Resiser4 naproti tomu vykazuje příkladnou efektivitu, způsobenou zřejmě technologií tail-packing, která omezeuje výrazné slack-space (přes 50MB/20% dat na ostatních FS).
S použitím transparentní komprese se výsledky vyrovnávají (akorát EXT3 je diskavifikováno...). Neznámou je opět spotřeba místa pro metadata u Reiser4, teoreticky by se tedy mohlo NTFS posunout výrazněji dopředu.
Závěr: nad transparentní kompresí by neměl být ohrnován nos, neboť dokáže výrazně šetřit místem, aniž by kaldla nějaké překážky. Navíc šetří I/O provoz, což je největší úuké hrdlo.
Výsledky získány na Windows XP Home SP2 (ano, Home, pro toho pohádkáře někde dole, haha!). Velikost clusteru 4KB. Šlo o datovou partišnu, takže by nemělo dojít ke zkreslení výsledků vlvivem dočasných souborů, cache browseru apod. Děkuji své rodině za podporu, panu prezidentovi (ne!), etc and all taht rott. Love anv peace! -
Uživatelce zkrouhli nick (neregistrovaný)Doplnění: po smazání zdrojáků zůstala MFT v původní velikosti 108MB, jen obsazení kleslo z 99 na 77%, volné místo je nyní 808MB. Jsou tedy zřejmé jisté nepřesnosti. Windows nepočítají obsazení MFT do použitého místa... ví někdo, jak je to s du?
A ještě oprava, hodota u Reiser4 s použitím transparentní komprese je vypočtená přes volné místo, takže je samozřejmě plně srovnatelná s NTFS a Reiser nemá metodologickou výhodu, jak je nezančeno v původním příspěvku, omlouvám se za opomenutí.
Je možné, že Reser4 neumožňuje tail-packing při kompresi, jako NTFS neumožňuje MFT resident ukládání souborů při kompresi? To by trošku vysvětlovalo pouze remízu s NTFS (čekal jsem vátězství). -
Tomáš Raček (neregistrovaný)
Debil nejste, jen jsme se trochu nepochopili. :-) Myslel jsem, že používám patchnuté gentoo-sources ne jako adresář pro test, ale že mám kernel zkompilovaný právě z těchto zdrojáků (samozřejmě patchnutý, viz odkaz výše). Jinak gentoo-sources je jen AFAIK patchnutá vanilka od vývojářů Gentoo. V prvním měření jsem používal zdrojáky 2.6.25, teď, abych to nějak sladil s vašimi výsledky, jsem stáhnul přímo verzi 2.6.25.9 z www.kernel.org. Pro představu ta má komprimovaná gzipem asi 60MB.
Zkusil jsem tedy znovu všechny testy (vyhodnocoval jsem pomocí
df -h, když seduukázalo jako nefunkční - na netu lze dohledat, že má problém právě s compress pluginem). Do testu jsem zahrnul ext3, ReiserFS (i s notail) a Reiser4 (bez komprese, s defaultní lzo a nakonec gzip kompresí). Pro tyto účely jsem vyhradil +-5GB partition (víc fakt nešlo, už tak je to osmina mé diskové kapacity:-))Nejprve tedy vytvoření FS, pro úplnost uvedu i příkazy:
mkfs.ext3 /dev/hdb3
mkfs.reiserfs /dev/hdb3
mkfs.reiser4 /dev/hdb3
mkfs.reiser4 -o create=ccreg40,compress=lzo1 /dev/hdb3
mkfs.reiser4 -o create=ccreg40,compress=gzip1 /dev/hdb3
FS: ReiserFS ReiserFS (notail) ext3 Reiser4 Reiser4(lzo) Reiser4(gzip) Počáteční obsazené místo: 33MB 33MB 138MB 284KB 284KB 284KB Zde by bylo asi na místě zmínit, že aktuální naformátovaná kapacita je asi o 150MB menší v případě Reiser4 (tolik tedy vysvětlení k na první pohled nízkým hodnotám u tohoto FS).
A už teď samotné využití prostoru:
FS: ReiserFS ReiserFS (notail) ext3 Reiser4 Reiser4(lzo) Reiser4(gzip) Obsazené místo: 317MB 343MB 455MB 274MB 174MB 89MB Po odečtení: 284MB 310MB 317MB 274MB 174MB 89MB Samotná velikost je tedy nejmenší u Reiser4 s gzip kompresí (jak je to s rychlostí čtení, zápisu ap., už je otázka na nějaký další test), možná by ještě nebylo od věci zkusit, jak je na tom velikost metadat na větší partition, žel na to možnosti nemám, třeba někdo přispěje svými zkušenostmi. :-)
-
Uživatelce zkrouhli nick (neregistrovaný)Moc pěkné, díky!
Tedy gzip docela ukázal zoubky... to bych do něj neřekl. NTFS používá tuším lz77 (tvrdí wikipedia).
lzo je prý extrémně rychlé, zatímco gzip by měl být deflate, čili lz77+huffman. Co si tak vzpomínám, tak už by větší provoz na disku (30MB/s+) asi vedl k znatelnému vytížení cpu (desítky procent), takže gzip opravdu jen pro zřídka používaná data (zálohy po aktualizacích; manuálové stránky - sjou jich mraky, ale potřebuejte vždy jen malý drobek).
