Já bych řekl, že Reiser4 je už dávno mrtvý. Roky se snažil dostat do jádra, ale nepovedlo se. Můžou za to některé jeho technické vlastnosti, které nejsou kompatibilní s POSIXem a Hansova sociopatičnost. Škoda, ale jinak už to nebude.
Klasických souborových systémů je docela dost, takže R4 nebyl nikdy nějak akutně potřeba. Nové FS jsou potřeba pro nová zařízení, jako SSD, které mají jiné vlastnosti, než ty točící se placky.
Zkrátka bez R4 se budem muset obejít. Jako uživatele ReiserFS mě to trochu mrzí, ale přežiju to.
Muzu se zeptat jak jste ty ReiserFS filesystemy zalohoval? Nejaky find, cpio, tar??
Bohuzel tohle byla a je zasadni nevyhoda ReiserFS, ze neexistuje "nativni" nastroj na backup....
No já zálohuju přes rsync, což je FS-independent. Tvoji potřebu "nativního" zálohování pořádně nechápu. XFS má tuším dump/restore, což se pravda hodit může, ale já osobně vystačím se zálohováním, co jede po souborech.
On rsync neni spatny, ale pokud musis zalohovat v enterprise prostredi, navic u zakaznika, tak ten v drtive vetsine pozaduje neco, co umi zalohovat na LTO, atd...
To, ze se neco nehodi pro jednu aplikaci, neznamena, ze se to velmi nehodi nekde jinde. Domacim uzivatelum je obycejne nejaka zaloha na LTO uplne ukradena.
vidim to stejne.
jako "byvaly" reiserfs linuxak pokukuju po xfs
reiser a ext3 jsem dlouhou dobu pouzival a mel jsem v 1 adresari(reiserfs) asi 4mil. souboru. a fs to ustal. s ext3 jsem zkousel jen 300tis. uvidime co na to xfs :-)
na ntfs bylo taky tech cca 4mil souboru, ale hdd to nejak odrovnalo. pricitam to chybe v sw (windoze server 2003 - tusim).
Myslim ze by stalo za to ho ozivit - nektere napady v nem byly unikatni a docela zajimave (treba pridavani uzivatelskych funkci, ktere by z dat na disku vytvarelo virtualni soubory). Vypada to, ze to jen neni dodelane (snad by to pak slo dostat do stavu, kdy to zvladne POSIX).
Myslim, ze by se takovy FS na nektere veci docela hodil. Je ale otazka, zda to je schopen nekdo prevzit...
Jinak klasicky ReiserFS je skvely hlavne kvuli tomu, jak alokuje male soubory.
No já mám pocit, že tam byly právě věci jaksi "nad rámec" POSIXU - třeba možnost připojit soubor jako adresář (každý řádek v tom souboru se pak tváří jako samostatný soubor). Což je fíčura, kterou kerneloví hackeři nějak nepřenesli přes srdce.
Oživit.. No on je IMHO hotový. Jsou tací, co to používají. Ale jelikož to nikdy nebylo ve vanilce, nění to otestované... Prostě by to potřebovalo za asistence zkušených vývojářů vyzrát.
Mival jsem reiserfs 3 kvuli jeho rychlosti, ale nekolikrat se mi docela zhroutil (pouze fs, pomohl pouze restart, fs check trval nekolik hodin na 300G disku). Presel jsem na XFS, tam si ale porad nejak nemuzu zvyknout na jeho "pomalost" oproti reiseru. Opravdu se mi zda ze xfs je pomalejsi a narocnejsi nez reiserfs.
myslim, ze to neni az tak pravda, z vlastni zkusenosti jsem neprisel o data na xfs pri vypadku proudu, ani kdyz mi dite vytahlo externi usb disk, na kterej se zapisovalo
a mate -o nobarrier? to pomaha pri zapisu
xfs je mozna o trosku pomalejsi i tak, ale robustnejsi, dobre opravitelny a cas na prvni primountovani je o dost mensi nez reiser a dokonce i rychlejsi nez ext3
fsck je taky rychlejsi nez ext3 nebo reiser, akorat mi trosku vadi, ze chce predtim namountovat a odmountovat, pokud v logu neco je, mozna by to mohl delat ten samotnej fsck
Filesystem "md1": Disabling barriers, not supported by the underlying device
primountovano s "noatime,logbufs=8,logbsize=131072" a vytvoreno mkfs.xfs -f -l size=32768b,version=2
toto jsou doporuceny parametry ze SGI mail-listu, ktery pouzivam:
mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 /dev/neco
mount -o logbsize=256k /dev/neco /mnt/neco
And if you don't care about filsystem corruption on power loss:
mount -o logbsize=256k,nobarrier /dev/neco /mnt/neco
akorat agcount mam 2, protoze mam single-cpu
novejsi mkfs.xfs myslim ma podobny defaults, krome lazycounts
Mohli byste prosim nekdo pridat zkusenosti jak je na tom Reiser s rychlosti oproti ostatnim fs?
Ja Reiser nikdy nezkousel. Pouzival jsem vzdy ext3.
Za sebe muzu pridat svou malou trosku do mlyna: ext3 je vyrazne vykonnejsi pri praci s malymi soubory nez NTFS. (Ale je otazka, jestli je to fs nebo operacnim systemem. Zkousel jsem build jednoho vetsiho projektu v jave - na Linux + Ext 3 = 17 minut, na Windows + NTFS = 45 minut. Vysledek podobny na mnoha pocitacich a distribucich linuxu.)
Z těch lidí, kteří u nás jedou na Linuxu, používá značná část na zdrojáky a jejich kompilování právě ReiserFS (verze 3.6) - právě kvůli rychlosti. Jo, shodou okolností tady děláme na jednom větším projektu v Javě. Takže doporučuju zkusit si ten benchmark ještě s ReiserFS, třeba by výsledek byl 13 minut.
Co se týče zkušeností a rychlosti, je to vždycky flejm jak prase :-)
Já před lety přešel z ext3 na ReiserFS a subjektivně se to zrychlilo. Ale na druhou stranu ext3 se dá tuším dost poladit, že to pak vyjde skoro na stejno.
Objektivní nevýhoda R3 je jeho dynamický layout (stromy). Když se to posere, může být problém. Na druhou stranu ext3 má statický layout, takže i dost poškozený FS jde alespoň z části přečíst.
Ext3 je ultrakonzervativní, což má výhody v robustnosti, ale zase mě neskutečně irituje, že se mu při formátování musí říct, kolik bude inodů, což je humus - buď zbytečně zabírají místo, a nebo dojdou :-)
Taky jsem slyšel, že R3 se pomalu mountuje, pokud jsou oddíly opravdu velké. Na svém notebooku jsem to pochopitelně nezpozoroval a taky jsem slyšel, že už se to vylepšilo.
Pouzival jsem reiserfs 3, nikdy zadna ztrata dat, s -notail nejrychlejsi, nejefektivnejsi
fs, co jsem kdy mel. Vzdycky jsem byl posrany strachy, co az to spadne a budu potrebovat
obnovit data, ale nestalo se. Zalohoval jsem arkeiou, no problem.
Behala na tom posta cca 70-ti IT lidicek (isp), drtiva vetsina ruzne automaticke nesmysly,
imap s "co mail, to soubor" - takhle rychly imap sem uz pak nikdy nemel.
Na stejnem systemu byly SMB home adresare.
Preinstalovaval a migroval jsem to cca 4x, z no-name PC, pres nejaky brutal shity e-commerce s pseudo-raid radicema az po 3ware.
Jedinej problem bylo omylem nevypnuty "-no-tail", pak bylo lepsi pres noc prenyst data
na novej svazek. Dost to zpomalovalo (ale furt rychlejsi a spolehlivejsi nez ext3)
2x za cca 4 roky sem mel selhani, dycky to byl "/" nebo "/usr", protoze byl na ext3 a po nekorektnim odmountovani pri cyklickym vypadku proudu neprezil vypnuti behem fsck.
Na rozdil od reiser, tam zadnej fsck po vypadku proudu potreba nikdy nebyl :-)
Já myslím, že pohřební řeči nejsou na místě. Psaní open source aplikací je veřejně prospěšná činnost, tak by ho snad ve vězení (večer, po práci v kamenolomu) mohli nechat programovat.
Moje osobni zkusenosti s reiserfs (3 i 4):
1) Nakonec se rozbije.
2) Az se rozbije, tak zustane rozbity.
3) Nema security labels, takze s nim nefunguje selinux.
Dal uz jeno v4:
4) V navrhu byla spousta dobrych napadu, ale nevidel jsem je implementovane.
5) Na vetsine kernelu (-mm) od 2.6.17 dal mi kvuli reiserfs spadnul/zamrznul system jeste pred zalogovanim
6) Prestoze jsem FS nekolikrat opravoval, zustal rozbity do te miry, ze se objevovaly chyby pri cteni na konci nekterych souboru a obcas to spadlo pri *mazani* souboru ...
Ze by byl rychlejsi (at uz ve verzi 3 nebo 4) jsem si nevsiml (BTW: co s tim rychlostnim porovnanim udela prepinac -pipe?), akorat vim ze jsem s nima mel vic volneho mista (i po odpoctu rezervovaneho mista) nez na ext3. (resp. ukazovalo se min "skutecne obsazeneho" mista pri df)
s volnym mistem je to pravda, reiser delal tail-packing, maly soubory se strci do nevyuzityho necelyho bloku za jinej soubor, dalo se to vypnout prepinacem, prej treba grub to nemel rad, ale myslim, ze pak uz mu to ani nevadilo
gcc (a predpokladam ze i jine prekladace) maji prepinac -pipe, ktery zpusobi, ze misto vytvareni mezisouboru na disku se budou prohanet rourama. Pochopitelne vysledny efekt zavisi taky na tom, jak je postaveny build-system ... a na tom, jestli treba /tmp neni ramdisk ... a dalsich vecech