Názory k článku
Reiser4: Mrtvý souborový systém?

Článek je zajímavý. Nějak jsem ale nepochopil, proč je vůbec uvedeno to porovnání s ext3... Na konci je napsáno, že testy nemají vůbec žádnou vypovídající hodnotu, neni pak takový testování naprd? :-D Buď skutečně nemá žádnou vypovídající hodnotu, pak ale nemá ve článku co dělat, nebo nějakou vypovídající hodnotu má, ale pak ve článku zase nemá co dělat ten alibismus autora...

Ta veta na konci je opravdu priserna. Chapu, proc jste ji napsal, ale formulace je opravdu tragicka. V soucasne podobe to vypada, ze ty testy jsou opravdu uplne k nicemu.
Zmente to, at to vyjadruje skutecne vyhrady k vysledkum:

1. Testy nevypovidaji o celkove kvalite filesystemu (mohl jste udelat vic rozdilnych testu)
2. Metodika testu neni perfektni

Poznamka k bodu 2 - zadna metodika neni nikdy perfektni a zadne mereni neni "presne"

No a k bodu jedna bych měl, že to opravdu nevypovídá o kvalitě FS. Co je to kvalita FS? Rychlost? Spolehlivost? Jak měřit spolehlivost? :) Já se chci spíš bránit faktu, že někde můžou mít také porovnávací testy a ty budou mít úplně opačné výsledky. Který test je pak správně?

Nestačilo by upozornění, že uvedené testy jsou spíše orientačního charakteru a nikoliv reprezentativní benchmarky?

Není jeden univerzální výsledek, univerzálně nejlepší FS. Testy by se musely provést v reálném provozu a vycházet z celkové odezvy daného stroje.

Třeba na notebooku mi je fuk, zda se film smaže za jednu nebo dvě sekundy, ale podstatné je, jestli mi opera naběhne za tři nebo za pět sekund. Jistě, nejsou to závratné rozdíly, ale co si budeme povídat - právě tato drobná zdržení dráždí nejvíce :-)

U Reiser4 oceňuji především transparentní kompresi, kterou jiné FS zatím moc nenabízejí. Podle některých testů je odezva systému na komprimovaném disku až dvakrát větší, protože CPU se většinou fláká (platí zvláště na desktopu). Samozřejmě nemá smysl na komprimovaný oddíl nahrávat mp3 a filmy.

Kdyz uz delate nejake testy, tak byste to mel delat trosku vedecky. Kdyz uz nic jineho, tak ten test opakovat nekolikrat (10x ?) a pak ty hodnoty zprumerovat nebo vynest do grafu (prehlednejsi).

Pokud se obavate o zasah nejakeho daemona do vysledku mereni, doporucuji to provadet z nejakeho live CD, kde vetsinou moc deamonu nebezi.

Take nechapu porovnani ze zastaralym ext3, kdyz jste sam psal, ze jste zkousel i ext4. Daleko hodnotnejsi by bylo porovnani etx4 a reiser4.

Mozna by stalo za to si vytvorit script, co by vam automaticky vytvarel souborovy oddil s urcitym file systemem a pak provadel testy s kopirovanim, presouvanim a mazanim souboru a adresaru. Vysledky testu ukladat do souboru a ten pak analyzovat vyse uvedenym zpusobem. Takove testovani by bylo opravdu hodnotne. Mozna by to stalo za samostatny clanek.

Děkuji za nápady. Plánuji napsat článek zabývající se pouze testováním souborových systémů a tam si dám opravdu záležet na metodice. Vyhradím si na to zvláštní stroj se systémem, který nebyl určen nikdy na nic jiného. Skript na testování mám a každým článkem ho doplňuji o další testy. Porovnání s ext3 jsem zvolil, protože byl Reiser4 původně stavěn vedle ext3 a chtěl jsem, aby se čtenáři mohli těšit na porovnání ve zmiňovaném článku :) Skript má výstup do HTML a není problém ho upravit na výstup do nějakého grafu. Bude zveřejněn spolu s článkem.

Tim mountnutim a odmountnutim bych si nebyl jist, radsi:

echo 1 > /proc/sys/vm/block_dump

Najdôležitejšie je IMHO nespúšťať testy na prázdnom oddieli, pretože tam je napr. lineárne hľadanie voľných blokov v zozname u ext3 rovnako rýchle (alebo rýchlejšie) než ich hľadanie v B+ alebo B* strome (podobne u ostatných jednoduchších štruktúr).

Ideálne spustiť 3-4 várky testov, napr. s 30%, 60%, 90% a 97% zaplnením oddielu. Súbory na oddiel nakopírovať pri každom teste rovnaké, pár veľkých (5-10x ~100MB-1GB), viac stredných (10-100x 1-50MB) a spústu malých (10000-100000x 1kb-20kB), potom nejakú časť z nich zmazať, zopár súborov nakopírovať naspäť a až potom pustiť test (simuluje to skutočné použitie, možno to mazanie a kopírovanie párkrát zopakovať). Spraviť na to skript zrejme nebude nič zložité.

K ucelmu testovani se nadmiru hodi resim single, kdy opravdu skoro nic nebezi.

Jinak bych se přimlouval i za testy efektivity ukládání a využití prostoru a disku - zkrátka jak moc které FS plýtvají nebo šetří místem.

Mit na to zvlast jeden stroj je sice hezke, ale podle me i kontraproduktivni. On jinak se souborovy system chova kdyz je novy, prazdny a jinak kdyz ho pul roku pouzivate. Behem prace snim po nejake delsi obdobi, se udela hromada zmen v datech na nem ulozench, spousta souboru se zmensi, zvetsi, smaze, vytvori atd.... Uzivatel, pro ktereho jsou pak ty testy (predpokladam, ze cilovym publikem je uzivatel, ktery se rozhoduje, ktery filesystem zvolit) urcene nebude mit prazdny, nebo nove naformatovany filesystem s nekolika novymi soubory. Jeho zajima jak se to bude chovat i za 2 roky pouzivani.
Chapu ale ze se to hodne blbe testuje.

No, NTFS je fajn, ale třeba transparentní komprese souboru u něho znemožňuje uložení v MFT, takže pak paradoxně malý soubor zabere těch 4KB místa (podle clusteru), místo aby zabral 0. Do MFT se prý za některých okolností (málo metadat) vejdou až 800bytové soubory, tudíž bez alokace clusteru! Takže reiser s tail packingem a navíc transaprentní kompresí je nejspíš efektivnější. Chtělo by to pro NTFS nějakou utilitu, která tohle zkoumá, a ruší automaticky compressed atribut u mrňat, která by se dala celé zapsat do MFT.

Ten wandering řurnál zní moc hezky. Podle mě je chyba chtít pluginy ve VFS. Četl jsem, že jde o nedorozmění, protože ve VFS by to nefungovalo a nebylo by to šikovné. Holt někdo v jádře si myslí, že sežral všechnu moudorst... což je bohužel obecná lidská nemoc.

Člověk si musí vzpomenout (mimo jiného prý pro unix charakteristickou) na architektonickou zásadu "worse is better", haha :)

Ještě kdyby z toho vychytali ty bugy. ;)

V Reiseru 4?

JJ, take bych rekl, ze spoustu veci umel NetWare uz na svem Traditional FS. Deleni bloku pro mensi soubory, moznost obnovovani souboru i jednotlivych verzi, transparentni komprese dele nepouzivanych souboru, pripadne moznost presunu do paskove knihovny u hodne dlouho nepouzivanych souboru a v pripade potreby jejich presunuti zpet na disk (toto jsem nemel moznost vyzkouset), podpora ACL, ruzne namespace (moznost pojmenovavani souboru podle pravidel ruznych OS). NSS pak prineslo mimo jine zurnalovani a vlastnosti "LVM". A to uz jsou leta. Docela by mi zajimalo porovnani vykonostni, ale to asi bude problem ziskat.

Nebo spíše usnul...
Ale je to fakt, OSS kopíruje M$ jak jen může, jen to stihne o pár let dřív, než to M$ "vymyslí".

To jste vystihl docela pekne. :-)

No vsak jo, OpenLDAP + Kerberos ... kdy to bylo v linux a kdy ve win, i Novell priznava, ze okopiroval LDAP, ovsem byl mozna 1. koho to napadlo pouzivat i na neco jineho, zen zdilenou DB emailu a kontaku, k cemuz byl puvodne urcen.

Nicméně libovolná odpověď ano na kteroukoliv nebo všechny z těchto otázek neneguje to, že byl první a lepší :)

Netware nabizel fileserver v dobe, kdy MS o necem takovem vubec jeste ani nic netusil. Pak MS prisel s Windows, ktere se daly sitovat a mohly slouzit jako fileserver. Ovsem ve srovnani s Netware dosti smesne. Prvni pouzitelny fileserver od MS byly Win NT, ovsem myslim si, ze tehdy Netware byl porad jeste lepsi a spolehlivejsi. Slysel jsem neco o tom, ze Novell si trochu natloukl kokos pri pokusu udelat Netware s grafickym meziksichtem. Dale asi hralo roli to, ze nezvladli verze 4.x, ktere byly o dost slozitejsi, nez predchozi a mohutne zabugovane. Roli sehraly i podrazy Microsoftu, ktery jednu dobu vyradil podporu pro Netware z Windows. Pak byly asi i nejake mensi MS typicke podrazy, treba sitova verze Foxpro, tehdy docela dost pouzivana, mela na diskete knihovnu, ktera umoznovala vyuzivat transakce Btrieve na Netware v dobe, kdy Bill Gates o existenci transakci jeste ani necetl v novinach. Kdyz pak Fox Inc bylo koupeno Microsoftem, vydali to same Foxpro, jen se zmenilo logo a, maly detail: na te diskete zahadne chybela ta jedna knihovna.

Nejak nechapu to vase povidani. Ano, Netware nabizel v te dobe neco, o cem MS teprve snil. Avsak porovnavejte soucasnost, pres vsechny ty povidacky pri volbe groupware do firmy vychazim ze soucasnych dispozic a moznosti. Tezko bych dnes prosadil Netware jen proto, ze byl prvni. To je argument jak Brno (nic proti Brnu).

Bohuzel ve sve praci mam co do cineni s nejnovejsim Groupwise i AD. Neodvazuji se rict, co je mensi zlo, ale MS rozhodne nevychazi draz (tak jak se casto argumentuje).

Novell dnes proste nestiha.

NetWare to IMHO ve velkem projel na nekolika vecech. NetWare byl a IMHO je stale asi nejlepsi FS ktery byl. Dneska se ale od serveru ocekava podstatne vice, nez jen funkce souboroveho a tiskoveho serveru. A tento prechod IMHO moc NetWare nezvladl. Aplikacni servery se delaly zpocatku na UNIXU, pozdeji Linuxu. Dneska taky skoro kazda aplikace chce DB a dost casto narazite na to, ze vyzaduje MS SQL. Tady MS tezi z velke zakladny tretich firem, ktere vyvijeji pro platformu Windows.

Pak se dostavate do stavu, ze byste museli mit v sitovem prostredi nekolik runych systemu, coz Vam komplikuje sitove prostredi a tedy i jeho udrzbu a potreba vice kvalifikovanych lidi pro ruzne systemy. Ve vysledku se to zacne prodrazovat. Zejmena, pokud jste mala firma. Nemluve o tom, ze v tomto segmentu dostanete slusny "balik" v podobe SBS serveru za akceptovatelne penize.

Novell se na tuto situaci ted snazi reagovat pres SUSE a migrovani NetWare sluzeb do Open Enterprise serveru, jenz se snazi postavit na Linuxu se zachovanim sluzeb a toho dobreho z NetWaru. A snazi se demonstrovat, ze tu existuje plnohodnotna alternativa ke svetu MS. Snad se mu to podari.

Muzu to demonstrovat treba na jedne siti, na jejiz sprave se podilim. Zakladem sitoveho prostredi je Novell a s doplnenim o ZENWorksy a GroupWise spokojene funguje jako sitove prostredi pro uzivatele s Windows. Kdyz jsme zacali resit nektere aplikacni servery, z pocatku se nam to darilo delat na Linuxu. Nicmene s pozadavky na nasazeni nekterych aplikaci, nebo s rozvojem aplikaci jiz provozovanych, jsme zacali potrebovat jako aplikacni srver i MS Windows Server (SQL a IIS). K tomu se pridal pozadavek na vzdaleny pristup a moznosti prace s Win aplikacemi na dalku. Logickym krokem tedy bylo nasazeni Windows terminal serveru. Takze kdyz to shrnu, provozujeme ted celkem tri platformy. Chapu, ze potom je tlak na zjednoduseni sitove architektury a vysledkem je v dost pripadech prechod na platformu MS Windows. Ac neni nejlepsi, zvlada tak nak dobre vsechno potrebne.

K tomu dobre zvladnuty marketing a i blizkost tohoto prostredi managmentu, vzhledem k tomu, ze ho provozuji na dektopech.

Ono je s tím case insensitivness trochu problém. Převod malá-velká písmena je totiž závislý na locale. Třeba skoro všichni máme písmenko "I" a malý ekvivalent "i". Jenže Turci píšou to malé "i" bez tečky - prostě jiný znak, jiný unicode code point.

Má to výhody a nevýhody, třeba si myslím, že fakt není potřeba mít v jednom adresáři tři různé soubory Readme, README a readme. Ale zase je důležité, aby si FS velikosti písmenek pamatoval (to naštěstí ve Windows funguje). Ale já se osypu, když mi ve Win nějaký program zmrší obrázek.jpg na Obrázek.JPG.

Takže s tím, jak to funguje na Linuxu jsem spokojen - je to spolehlivé. Hledání souborů bez ohledu na velikosti písmenek zajišťuje třeba Tracker.

bude fungovat co? Komoleni pismen v turectine, nemcine a spouste dalsich jazyku kde prevod mezi malym a velkym pismenem neni jednoznacne? Jak ktomu prijde chudak programator kdyz dostane sileny bug-report z turecky, nemecky...-mluviciho local-u?

Naprosto nesouhlasím Radku.

Tohle schazovanání diskutérů označováním za Radka Hulána je pěkně nízký.

Prosímtě, netahej sem svého velkého guru Hulána.

Já Hulána nesnáším. NEvím, co mi chceš předhazovat. Zkrátka mám kritický postoj k některým věcem na linuxu a pozitivní názor na některé věci na windows. Jestli si myslíš, že tyto věci z lidí jako jsem já dělají kuřbuřty toho cvoka, nebo dokonce přímo toho cvoka jménem RH osobně, tak bys měl předplatit nějakou efragmentaci uvažování:)

to ze to nejde vypnout je naprosto pochopitelne. By me zajimalo co bys delal kdybys mel souborovy system, v nem dalsi adresare. jeden by se jmenoval projekt a druhy ProjeKt. Mas vyple rozlisovani malych a velkych pismen, a chces se dostat do adresare ProjeKt, inu napises do konzole cd ProjeKt a odentruujes. Co myslis jak ma pocitac rozlisit, do ktereho adresare jses, kdyz tebou zadane ProjeKt je uplne to same jako projekt nebo PROJEkT(nerozlisujeme mezi malymi a velkymi pismeny). Myslim, ze by se ti mohla libit nasledujici osetreni: program by se pak zeptal, jestli myslis adresar s inode 73149 nebo 63516 nebo 94856.
Jeste, ze case senzitivitu neresi programy, ale ma ji na starosti kernel.

Na windows se ti tohle naštěstí nestane.

Co by nestalo? NTFS velikost písmenek zachovává, a pokud se v témže NTFS adresáři nachází soubory, jejichž název se liší jen písmenkem (třeba když na NTFS oddíl přilezou z NFS serveru ;-)), tak ouvej. :-)

Právě. Na windows se ti to nestane, dokud se nějaký vtipálek nerozhodne, že vám ukáže "sílu unixu". Jiank při sdílení se o zápis stará lokální OS, takže by měl takovým srandičkám zabránit.

No já nevím. Instalátor SFU se (IIRC) ptá, jestli mají být non-Win32 subsystémy přepnuty do case-sensitive režimu, a pokud člověk chce rozumnou kompatibilitu, tak by to asi měl přepnout. Akorát pak může být problém s používáním týchž souborů z Win32. Člověk si asi nevybere, ale nevěřím, že by zapnutí téhle funkce působilo tolik problémů, jako její vypnutí.

Jinak opravdu nechápu, o jakou "sílu Unixu" by mělo jít. Souborových systémů byla a je hromada, včetně vůbec samotných modelů pro názvy (hostitelé v názvu souboru ano/ne, zařízení ano/ne, různé typy hierarchií (flat adresář, jednoúrovňové adresáře, libovolné stromy), typy souboru jako funkčně významná součást názvu ano/ne, číslo verze souboru ano/ne, povolená sada znaků v názvech, oddělovače jednotliých částí názvu (':','/','\'...), case sensitivity ano/ne)... Zatím vždycky po každých zhruba dvaceti letech vypadala mapa operačních systémů úplně jinak. To, že spousta systémů má vlastní konvence, to je nějaké "vytahování"?

Měl jsem tím na mysli případ, kdy by se linuxák-šprýmař rozhodl windowsákovi-chudákovi zbortit systém (no, snad jenom složku), aby už konečně pochopil, že tudy cesta nevede, a obrátil se:)

Nepoužívám Windows a na Linux jsem s case senzitivitou nikdy neměl problém. O čem to matleš?

Ale taky to, ze jej neumel korekne opravit, pri poruse FS na dikovem poli a pristupu na par souboru disk cely odpoji a ne jenom disk, ale cely radic, takze vsechny svazky, co mel pres FC sly do kopru a system se byl nefunkcni.

Pomohlo az nalezeni tech souboru, dat je do excludu, ZNOVA ZFORAMTOVAT svazek a obnova souboru, tomu nerikam spolehlivy FS, nastroje na opravu opravdu nestaly za nic, bavim se o novem FS, co umel to jakoze LVM.

NTFS neni fajn FS, nejen ze je temer na vse pomalejsi nez ext3, samozrejme porovnavat je problem, NTFS neni nikde jinde nez ve win rozumne implementovan, takze se na testech projevi i OS.

Dale NTFS nema journal, ty kecy ze jako ma, vychazeji pouze od lidi, kteri naprosto netusi, co to ten journal vlastne je, pokud jej ma, pak me zjimaji vlastnosti, jak je dat do jineho diku a jak lze jeho vlastnosti ovlivnit .... a proc se pri vypadku proudu checkuje cely FS

mozna zijes pod sutrem, ale ani XP Home NTFS nemaji, maji jen FAT. Jak je to ve Viste Home, nevim.

Pod šutrem žiješ ty. To ti někdo říkal? Mrky-mrky: disk C, formát souborů NTFS, Win XP SP2 OEM. Jak by si asi lidi dělali ISA DVD her do viruálních mechanik? :)

NTFS maji nejen Windows XP, ale mely je i Windows NT a Windows 2000. Takze pod sutrem zijete vy.

Na všem pomalejší, jo? Bych chtěl vidět. Podklady?

Jste poněkud mimo nejnovější verze NTFS je v3.1

Někdy se ty verze berou podle verze WIndows NT, takže V5 = to, co bylo ve windows 2000.

No .. vyzera, ze Reiser zabil 2 muchy jednou ranou :-D

Reiser zabil 2 rany 1 muchou!

ne, to byl Norris

Ještě by možná nebylo špatné uvést, kolik na disku zabírá ten adresář portage na ext3 a kolik na Reiser4. U mě rozbalený kernel 2.6.25 měl na ext3 317MB, na Reiser4 269MB. Ale to jen tak pro info. :-)

S kompresním pluginem nebo bez?

Dobrá otázka. :-) Spíš ne. Mountnul jsem to bez parametrů - pouze tam bylo (rw). Samotného by mě zajímalo, jak se to dá zjistit, i když se přiznám, že jsem po tom vlastně nijak nepátral.

OK, takže bez něj. Zadává se to už při mkfs.reiser4. Jdu to zkusit. :)

Tak du -sh ukazuje 1.6GB. Kde se stala chyba? :-) Údaj o využitém místě pomocí df -h už vypadá reálněji - 195MB.

du asi má s reiserem problém. Ale s čím, s cryptocompress, nebo s tailpackingem? Čekal bych spíš to druhé.

Použil jsem mkfs.reiser4 -o create=ccreg40,compress=lzo1 /dev/hdb3, takže cryptocompress. Teď hledám, jak se zapíná/vypíná tail-packing.

Podobne jak u reiserfs, notail option pri mountovaní (neovplyvní už existujúce súbory).

reiser4[mount(3515)]: parse_options (fs/reiser4/init_super.c:253)[nikita-2307]:
WARNING: Unrecognized option: "notail"

To je vanilla? Dáte mi odkaz, rádo bych zkusilo srovnat s NTFS.

Patchnul jsem gentoo-sources, ale asi v tom nebude rozdíl. Patch pro 2.6.25 naleznete tady.

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!

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í).

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ž se du uká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. :-)

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).

Kdy se Raiser priznal ke svemu cinnu? Snazim se sledovat vsechny informace o nem, aleni kde sem to nezachytil (snad kromne na Rootu, kde slo ale o spatny preklad puvodniho clanku).

Viz zprávičku Hans Reiser dovedl policisty k tělu vlastní ženy.

Tam se ale nepriznal, akorat ukazal mrtvolu..

Bystřejší už možná tuší...

To uz je opravdu "open" nabozenstvi...

Nebo strach z OSA.

Ten titulek článku mě vzhledem ke skutečnostem kolem vraždy pěkně pobavil :-)

bylo by mozne nepouzivat ceske ekvivalenty anglickych terminu? naprosto netusim co dat do google abych si o tom nasel neco vic...

v pripadech kdy je to jasne (strom <-> tree) tak je to ok, ale u takovychhle veci neni jasna terminologie a tak by bylo lepsi pouzivat originalni anglicke terminy.

jak tedy zni "potulny zurnal" v originale?

diky

V originále je to AFAIK "wandering log" (namesys.com je chcíply, tak nemôžem
overiť).

Poradím vám ještě lépe. Bylo by možné používat hlavu?

Strom použitý v Reiser4 nazývajú "dancing tree", čo je nejaká varianta B+ stromu (má mierne iné vyvažovacie pravidlá).

Journal: AFAIK sa zmeny vykonávajú na novo skopírovanom mieste, a nakoniec sa zmenia pointre, aby ukazovali na nové miesto. Miesto pre blok žurnálu sa vyberá tak, aby bolo blízko pôvodného bloku (minimalizovanie seeku pri následnom čítaní súboru).

Naviac tam existuje nejaká heuristika, ktorá označuje prepisované "wandered" bloky na "relocatable" a "overwrite" - hovorí to, či sa blok môže presunúť, alebo bude prepisovaný dva krát ako u klasického žurnálu (jedna kópia do žurnálu, jedna kópia naspäť). Dva prepisy môžu byť dobré napr. aby bloky "neodcestovali" príliš ďaleko, čo by zvýšilo seek time. Tá heuristika je založená na tom, či majú dirty bloky dirty parenta apod.

Ďalšie dve optimalizácie sú copy-on-capture a steal-on-capture, ktoré zabezpečujú minimalizovanie počtu transakcií, ak sa nejaký blok prepisuje viackrát, zapisuje sa len posledná transakcia na bloku.

Do súborov sa dá "cd"-čknuť, obsahom súboru sú pseudo-súbory reprezentujúce jeho atribúty apod; treba na to executable permission kvôli obmedzeniu VFS. S pluginami je teoreticky možné vytvoriť nekonečne veľké adresáre (súbor sa generuje on-the-fly). Pluginy naviac môžu "radiť" balancovaciemu algoritmu.

Podrobnosti sú na http://www.namesys.com/txn-doc.html, ale je to momentálne nejaké vychcípané. Viz tiež blog Danilova (jeden z vývojárov): http://nikitadanilov.blogspot.com/2006/03/reiser4-1-internal-tree.html

Existuje nejaka binarna distribucia Linuxu s ReiserFS4 (v instalacii) a taktiez s podporou vytvorenia RAID0 (v instlacii)? O nicom takom totiz neviem...

Uvedl jsem chybnou informaci. Reiser sice Namesys prodával, ale prodat se ho nepodařilo a tak se společnost nakonec rozpadla. Článek byl opraven.

Když vezmu v úvahu fakta, že

- původní Namesys na Reiseru4 nijak zvlášť (kromě grantu DoD) nevydělával a komerční featury jako online repacker nikdo sponzorovat nechtěl

- v kódu se vyzná akorát Hans (v base), tři programátoři Namesysu v Rusku, z toho jeden bývalý a jistý přehled mají Andrew Morton a Christoph Hellwig, kteří mají ovšem na práci mraky jiných věcí

- dodělávky některých věcí (třeba optimalizace fsync(), bez které se na R4 v podstatě nedají provozovat databáze) nejsou, jak Hans osobně uznal, triviální

tak to docela chápu.

Reiser4 me docela nadchnul. Uz jsem o tom psal v jine diskusi, ale daval mi nejlepsi vysledky pri pouziti s DVD-RAM!

Skoda, ze nejsem a nikdy nebudu programator. Ale nekdo z Vas pritomnych by mozna zvladnul pokracovat...

Osobne si myslim, ze opravdu umrit mohou jen uzavreny software (spolecne se svou materskou firmou), u opensource je vzdy nenulova pravdepodobnost, ze ho nekdo zas vzkrisi k zivotu.

To je otázka. Zvlášť když bude vidět, že není vůle pustit to do jádra.

Hm, kdyby aspoň to. Nicméně to bude mrhání zdroji.

Proč mrhání? Když se program napíše od základu, může to být časově méně náročné než se snažit předělat starý program.

To je BTRFS --- vvybralo nápady z ReiserFS a ZFS.

Používám Reiser 4 nějakou dobu, i když nikoli v produkčním prostředí. Jsem s ním spokojen, rychlost při práci s malými soubory nemá konkurenci, stabilita výborná, přestože Reiser 4 není dokončen. Chci jen uvést pár komentářů k výše uvedenému článku.

1) rozepře H. Reisera a vývojářů Linux kernelu: s Hansem není právě snadné vyjít, ale domnívám se, že v tomto případě je větší kus pravdy na jeho straně. Nakonec ten, kdo v diskusi reagoval iracionálně byl právě Ch. Helwig. Je škoda, že takoví lidé jsou zodpovědní za směr, kterým se Linux vydá. Hans asi udělal chybu, když se rozhodl svůj projekt implementovat v Linuxu a nevybral třeba některý z rodiny *BSD, situace mohla být asi zcela jiná...

2) Reiser4 pluginy: modularita je výborná věc, modulární software je flexibilnější, snadněji se debuguje, přidávají funkce... V oblasti file systémů to ale není běžná věc a navíc směr, kterým kráčí vývoj Linux kernelu je právě opačný, bohužel... Třeba VFS API (poprvé myslím implementováno v SunOS) takovou modularitu umožňuje, takže jakýkoli FS, který má toto API lze relativně snadno naportovat. Vše ostatní je (a měla by být) záležitost kódu samotného FS. V Linuxu se však stále více věcí implementuje obecněji přímo v kernelu (žurnály, schedulery...). Dle mého názoru je tento přístup chybný, jednak tím značně znesnadňuje portabilitu file systému do jiného operačního systému a naopak (příslušná část kódu nemusí být v jiném OS přítomna, resp. bude duplicitní v druhém případě). Za další klade překážky vývojářům v implementaci vlastních algoritmů (alokátorů, žurnálů, schedulerů...) a vnucuje jim vlastní kód. Tato snaha v konečném důsledku zredukuje file systémy na definici on-disk formátu...

3) současná podoba Reiser 4 je (resp. spíše byl) pouhou částí vývojového projektu, který Hans Reiser zamýšlel: cílem měl být file systém se schopnostmi relační databáze. Obecně file systémy a databáze mají mnoho společného a mnohokrát se vývojáři file systémů nechali databázemi inspirovat (b-tree, transakce, logy - žurnály, indexy, cesta v čase - versioning jako v postgres nebo Oracle...), ale vždy šlo o nějaký malý subset toho, co dokáže skutečná databáze. Finální ReiserFS, Hansem občas zvaný Reiser SSN - Semi Structured Namespace, měl umět to, co dělá každá relační databáze. Klasický FS má rigidní hierarchický namespace (pravda rigidita není úplně striktní, jsou tu linky a rekurzivní adresáře), kdežto relační databáze má v zásadě plochý namespace (dobře má tabulky, ale to je interní struktura) a namespace hierarchizuje per dotaz podle toho, na co se uživatel ptá. Pokud mne zajímá např. kolik klientů z DB zákazníků koupilo kombinaci několika konkrétních předmětů zformuluji dotaz a DB údaje vyhledá, odfiltruje, zformátuje a vrátí pěknou tabulku přesně na míru tazatele. V kontextu file systému by to znamenalo, že pokud chci znát, které všechny písničky v mp3 na mém disku mají v titulu slovo "utopia" zformuluji dotaz (pomocí GUI nebo specifického příkazu) a FS vrátí seznam. Podobnou věc samozřejmě mohu udělat v klasickém FS třeba za pomoci find, s tím rozdílem, že můžu hledat jen podle názvu souborů nikoli podle názvů samotných skladeb (optimálně s užitím indexu) a pokud mám velkou mp3 kolekci budu na výsledek čekat týden... Podobné schopnosti měl mít (nebo bude mít???) WinFS, tam ale šlo o vrstvu nad NTFS a obávám se, že rychlost by nebyla právě ideální. Reiser 4 měl být storage vrstvou, která prostřednictvím vychytávek typu dancing trees, wandering logs, transakcí... atd. umožní efektivní a rychlou práci a la relační databáze v Reiser SSN. Lze tedy říci, že větší část projektu zůstala nerealizována... Večná škoda.

4) Jen na okraj: vypadá to, že doba rotujících disků jakožto převažujícíh medíí k ukládání dat se pomaličku chýlí ke konci. Pro ně byl ReiserFS projektován (listy b-tree jsou na disku umístěny v sousedních blocích a využívá se tak největší přednosti klasického disku - rychlosti v kontinuálním čtení/zápisu) a se jejich ústupem se ztratí i výhody ReiserFS. SSD disky nejsou penalizovány za náhodný přístup, ale preferují (podobně jako RAID-5) I/O ve větších a zarovnaných blocích. Vypadá to, že nás čeká velký comeback jiného druhu file systémů. Těch, co zažily nástup v 90. tých letech minulého století a přesto se nedočkali praktického užití - s malou výjimkou file systému Spiralog od Digital Equipment blahé paměti. Jde o log-structured file systémy.

A.