Komu vadí reiser4?

15.7.2008 10:03 | Přečteno: 2471× | Jen tak na okraj

Také vás tak unavují ty věčné hádky která distribuce je nejlepší nebo který OS je nejlepší?

Ve víru vášní se často zapomíná na to, že preference každého jednotlivce formují nejenom zkušenosti kladné i záporné, ale také názory osob které respektuje a k nimž vzhlíží. Pod takovým vlivem se mnohé chyby, které by jinde byly ostrým terčem kritiky bagatelizují a naopak přednosti vychvalují do nebes.

Pro mne je linux přitažlivý tím, jakou mi dává svobodu. Jasně, občas si také popíchnu, ovšem nikdy by mě nenapadlo brát takový špílec vážně. A tak nechápu jak se někdo může na někoho sprostě osopit, jen proto že má jiné preference.

Můj oblíbený souborový systém je reiserfs. A od okamžiku kdy jsem zjistil, že příčinou chybovosti reiser4 u jádra -mm je špatná implementace patche, i reiser4. Fakt nechápu vyvolávače vášní, co na všechny strany trousí zvěsti, jak je reiser4 nefunkční a nikdy nebude dokončen. Láry fáry. Je dokončen a použitelný, ovšem byl navržen tak, že jej lze rozšiřovat pomocí pluginů, tudíž lze na něm pracovat dál, aniž by bylo nutné překopávat celý koncept.

Nejrůznější benchmarky mi přijdou naprosto nesmyslné, protože při praktickém nasazení bývá úzké hrdlo, které zpomaluje práci s diskem většinou úplně jinde. Reiserfs používám již šest let bez problému, protože mi vyhovuje že u něj nemusím nic řešit. Prostě připíchnu disk a přimountuju. Teprve s koupí 750GB disku jsem si řekl, že by možná mohl být reiser4 pro něj vhodnější, ale nakonec jsem na něj stejně dal "zajetý" reiserfs. Především proto, aby si mohli ten disk připíchnout i mí kamarádi, co nemají jako já jádro s podporou reiser4.

S výjimkou kořenového diskového oddílu (reiserfs) a diskového oddílu pro adresář /boot (ext2) však mám reiser4 všude. Také má svoje mouchy - očividně nejlíp je mu na velkých diskových oddílech, kde má dost místa.

Jsem toho názoru, že kdyby byl zařazen v nezmršené podobě do jádra, tak by si svou pozici jistě vydobyl v masovějším měřítku. Také si myslím, že by pak velice rychle došlo k odstranění "nedostatků" na které nestále poukazují ti, co brání jeho začlenění do hlavní vývojové větve jádra.

       

Anketa

Komentáře

[Michal Fecko]

...minimálne sprostý podozrivý, Hlaváčku...

[kotyz]

Ted kdyz policajtum ukazal kam schoval telo je to myslim jasny. Ale do ty doby sem taky veril ze to neudelal ...

[kotyz]

Me je zatim dobre na ext3 a tak do (pul) roka prejdu na ext4, ten je uz (skoro) hotovej, je v jadre (imho od 2.6.19) a brzy se zacne vic nasazovat. A co sem cet, tak si nevede vubec spatne (jo a online defragmentace zni mym usim libe).

[Aleš Kapica]

Co je to defragmentace?

[Aleš Kapica]

Teď ale bez legrace. Shválně jsem se kouknul jak to vypadá s fragmentací na mém diskovém oddíle s adresářem /usr který je na tom asi tak nejhůř (časté aktualizace, kompilace jádra, relativně malý prostor). Než to dojelo, tak to chvilku to zabralo.

stroj:/home/user# measurefs.reiser4 -f -D /dev/sda7
measurefs.reiser4 1.0.6
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING. 

Data fragmentation ... done                                                                                              
0.032064

Ještě si dovolím ocitovat z manuálové stránky..

The result is fragmentation factor - value from 0.00000 (minimal fragmentation) to 1.00000 (maximal one).

[Aleš Kapica]

Mimochodem, taková malá sonda. Již nějaký čas přemýšlím nad tím, že bych oprášil svou starou repository a dával do ní svůj binární deb balíček s jádrem. Jenom nevím jestli by o ně byl zájem.

[Aleš Kapica]

Mimochodem, ještě dodatek. Mám obě verze. Jak amd64, tak i386 (tu používám pro virtuály). Většinou vychází z aktuálního vanilla stable a lze s ním bez problémů zkompilovat jak modul pro fglrx, kvm, tak vmware (host i guest).

[trekker.dk]

Minimal fragmentation a maximal fragmentation jsou dvě opravdu vypovídající hodnoty...

[alpha]

IMHO se maximal fragmentation nedá dosáhnout – pokud je na 10GB disku 4,5GB film, který má alokované dva souvislé bloky o přesně poloviční velikosti, tak je fragmentace 0,225 (hlavní extent toho souboru se nepočítá, fragment má 2,25 GB). Alespoň si to tak pamatuji z nějaké dávné diskuse s Edwardem Šiškinem, je možné, že tu jenom hlásám bludy.

[alpha]

Teď mě ještě napadlo, že se ta fragmentace možná počítá jenom pro plné místo, takže by v tom mém příkladu byla 0,5. Už si to vážně nepamatuju.

[Kvakor]

Je vubec nekde definovano, jak se fragmentace pocita? Protoze jsem videl, jak kdysi jeste v DOSu ukazovaly dva programy ruznou uroven fragmentace, protoze jeden (jakasi utilitka na zobrazeni fragmentace) to pocital jako pomer velikosti vsech fragmenovanych souboru vuci celkove obsazenemu mistu, kdezto ten druhy (nortoni Speedisk) do toho nejspis zahrnoval i uroven fragmentace uvnitr jednoho souboru. Obe cisla se lisila o nekolik procent.

Je jasne, ze minimalni uroven fragmentace je nula, maximum by melo byt sto procent. Otazka je, jesltli tech sto procent znamena "kazdy soubor je fragmentovan" nebo "vsechny soubory delsi nez jeden blok nemaji zadne dva po sobe jdouci alokacni bloky za sebou". V druhem pripade se do toho jeste navic mota geometrie, protoze pokud jsou bloky blizko sebe, tak to nema takovy vliv, jako kdyz je kazdy na opacne strane disku.

Pokud se uroven fragmentace chova obdobne jako uroven entropie ve fyzikalnim systemu, mela by byt maximalni uroven fragmentace takova, ze by byly nejen vsechny soubory fragmentovany, ale ze by vsechny alokacni bloky byly rozhazeny na takovych mistech disku, ze by jejich precteni zabralo nejvice casu. Coz je teoreticke maximum, ale videl jsem disky s FAT16, ktere se tomuto stavu docela blizily

Nebo by se mela rozlisova uroven fragmentace souboru (kolik je jich fragmenovany), vazena na urovni souboru (jako predchdozi, ale krat misto), na urovni bloku (kolik skupin bloku neni souvislych), vazena na urovni bloku (to same, ale krat velikost skupiny) a nakonec fragmenace pocitana jako entropie, vuci stavu maximalni neusporadanosti, pripadne entropie jako (zaporna) mira informace, ve smyslu o kolik/kolikrat vice informaci potrebujeme na precteni vsech souobru (u nefragmentovanecho staci adresa plrniho bloku, u zcela fragmenovaneho potrebujeme adresy vsech). Otazka je, ktera hodnota by mela pro uzivatele maximalni vypovidaci hodnotu ....

[Aleš Kapica]

measurefs.reiser4 umožňuje zjistit několik typů fragmentace. To co jsem nechal vyjet já je průměrná fragmentace datových souborů, tj. pro každý soubor byla spočítaná zvlášť a výsledky byly zprůměrovány.

[trekker.dk]

Takže každý soubor má průměrně 0.032 čeho...?

[Aleš Kapica]

Šmarjá to je takový problém si domyslet, že když minimum je 0.00 a maximum 1.00 že bude průměrná fragmentace 3,2% ?

[thingie]

Fajn, a jak mam interpretovat informaci, že soubor je fragmentován 3,2%?

[andree]

napr. ze 3.2% dvojic fragmentov (=blokov, co maju byt za sebou) su na disku usporiadane inak, ako sekvencne?

[Aleš Kapica]

Údaj je není o fragmentaci jednoho souboru, ale je to průměr hodnot pro všechny soubory na tom souborovém systému. Jak si to číslo máte přesně interpretovat vám nepovím, protože mě osobně problém fragmentace nezajímá. určitě se to však dá vyčíst ze zdrojáku utility measurefs.

Jak už jsem uvedl v blogpostu, benchmarky mě nezajímají, pokud však o ně stojíte tak si klikněte. K tomu že jsem vůbec na tohle téma něco napsal mě vyprovokoval článek o ext4 který je na rootu, co se právě účelově takovými benchmarky ohání. Zajímavé že si autor nedal tu práci, aby srovnání provedl také s reiser4.

[Michal Kubeček]

Jak si to číslo máte přesně interpretovat vám nepovím

A to je právě jádro problému, protože žádný jednotný standard neexistuje a každý si to počítá, jak ho zrovna napadne. Přesto to některým lidem nebrání z těch čísel (velmi pochybné vypovídací hodnoty) vyvozovat dalekosáhlé závěry.

[Aleš Kapica]

Asi tak nějak. Pokud jde o mne, tak z dosavadního používání mi vyšel reiserfs jako takový pracovitý univerzál. Dá se na něj dostat z windows, při jeho mountování není třeba řešit nějaké speciální parametry, zkrátka funguje k mé spokojenosti. Adresář /boot dávám na ext2 z jednoduchého důvodu. S ničím se na něm moc nehýbá, žádné komplikované a předlouhé názvy se v něm také nevyskytují, žurnál je na něm zbytečný.

U reiserfs se mi osvědčilo oddělit si adresáře /usr a /var od kořene. Lépe se tak řeší ev. problémy v případě pádu stroje (el. výpadek, hrubé zacházení a já nevím co ještě). Taky mi přišlo že virtuální stroje s takto rozhozeným systémem jsou svižnější. U reiser4 mám naopak pocit, že mu nejvíc svědčí jeden velký diskový oddíl. Tam skoro vůbec nedochází k fragmentaci a také jeho checkování se mi zdálo rychlejší. Zřejmě tak může lépe hospodařit s místem na diskovém oddílu a neskáčou přitom tolik hlavičky. Pokud jde o rychlost při práci se soubory. Víc mě limitují otáčky notebookového disku, než souborový systém.

[trekker.dk]

Přesto to některým lidem nebrání z těch čísel (velmi pochybné vypovídací hodnoty) vyvozovat dalekosáhlé závěry.

Asi tak nějak.

Vzhledem k tvému příspěvku s measurefs jsi jeden z těch lidí...

[Aleš Kapica]

Ty jsi ale vážně kus.. (prosím dosadit libovolný kus hovězího). Přihodil jsem to jen pro zajímavost, protože jsem byl na to sám zvědav a celkem důvodně na to mohl být zvědav i ten kdo reiser4 nepoužívá.

[M. Lox]

Z mého (alphova, konečně jsem si založil účet) vysvětlení vyplývá, že fragmentace limitně se blížící k jedné (0,99999999…) je maximum, které znamená, že na disku je každý soubor fragmentovaný, a to tak, že jeho první (myslím, že v originálním vysvětlení bylo slovo hlavní, což by taky mohlo znamenat největší) extent má délku jeden blok a zbytek je v jiném/jiných extentech.

[kotyz]

Me to ext3 kdyz delam fsck hlasi v %. Na / mam pod 10 % a na /home asi 12 % non-contiguos souboru (to by mela bejt ta fragmentace). Prej existuje i nejakej nastroj na defragmentaci (ale jeste sem ho na vlastni voci nevidel).

[Brokarna]

Taky sem o nem slysel a nikdy ho nevidel .

[Heron]

Článek hodnotím kladně, ale ...

Mým oblíbeným FS je XFS. Při návrhu diskového pole 3TB v RAID5 = 2TB, jsem však vybral ext3 (a to i přes jeho zjevné nedostatky pro takto velká úložiště). Důvody jsou následující: CentOS (RHEL) nic jiného neumí. Do enterprise distribuce a na server si nebudu kompilovat vlastní jádro (či centosplus). Dále, ext3 je nasazen na většině linuxových systémů, je tu doma a jsou s ním největší zkušenosti = při problémech teor. nejlepší šance najít řešení. Až bude ext4 stable (tj rok, dva po nasazení na desktopech), lze ext3 převést na ext4 jedním remountem.

Toto jsou i důvody proč nechci reiser4. Jistě, je to asi skvělý systém by design, ale to, že není v jádře má svůj důvod a tím pro mě jako by nebyl.

[Michal Kubeček]

Také pro velké filesystémy upřednostňuji XFS, ale na některých strojích jsem narazil na neuvěřitelnou pomalost některých operací, např. příkaz sync trvající i 20 sekund a podobně dlouhou prodlevu při vypínání virtuálního stroje pod VMware. Takže jsem zkusil nasadit JFS a zatím jsem spokojen.

[alpha]

Já mám Reiser4 skutečně všude, až na flashdisk, se kterým chodím do školy – tam je ext2 – dokonce i na DVD-RAM. Musím říct, že jeho používání je velmi výhodné pro všechny Gentooisty, neboť vyhledávání v Portage nebo emerge --sync se tím zrychlí skutečně několikanásobně, a to i oproti ReiserFS. Není ani potřeba ho používat na celý /, stačí si Portage strom hodit do souboru do loopbacku.

[krab1k]

A používáš patchnutý kernel nebo -mm? Zase jsem totiž o Reiser4 začal uvažovat.

[M. Lox]

Patchnutý, mm je Mortonův sandbox, takže z poloviny nefunguje.

[kralyk z abclinuxu]

Proc tam chybi:
Nepouzivam ho, protoze nechci / mam jiny fs ...

[freshmouse]

c) je správně: nepoužívám ho, protože této problematice nerozumím a nezajímá mě a v Ubuntu je výchozí Ext3...

[David Ježek]

přesně to vystihuje můj postoj. nevím , která zde bije a jednoduše používám to, co je v distribuci defaultní (tedy např. ntfs ve wvu </joke>:-))

[Smajchl]

Presne tak, neznam reiserfs4 nevim jestli je to problemovy nebo ne a jsem spokojenej s reiserfs a ext3 - funguje to tak neni co resit.

[Luboš Doležel (Doli)]

Naposledy jsem Reiser4 zkusil v roce 2005, kdy už o něm někteří tvrdili, jak je stabilní, a bylo to takové rodeo, že tentokrát raději počkám.

[#Tom]

Podporuje už ReiserFS4 ACL? Když jsem to před asi dvěma až třemi lety zkoušel, tak to ještě nešlo, a nemám čas a chuť to teď zjišťovat…

[Algi]

Můžu se zeptat? Jak vlastně ACL fungují? Je k tomu někde nějaká dokumentace? Moje představa je taková, že ACL jde na souboru nastavit ve Windows pomocí klikátka, ale když jsem na Linuxu nebo Mac OS X? Rád bych například označil složku za skrytou, aniž bych na začátek názvu dával tečku. Je to pomocí ACL možné?

[#Tom]

O ACL (access control lists) toho vím málo, takže jen stručně. V Linuxu vyžadují podporu jádra a balík pojmenovaný obvykle acl. Potom je třeba připojit oddíl s parametrem acl a práva se nastavují příkazy setfacl a čtou getfacl. Jde nastavit čtení, psaní a spuštění pro konkrétního uživatele, skupinu, nebo jako masku (potlačí nezadaná práva), totéž pak lze u adresáře nastavit jako vzor pro nově vytvářené soubory (parametr -d). Že by se tak daly ukrývat soubory, to nevím. Dále odkazuji na manuálové stránky acl(5), getfattr(1), setfattr(1).

Kromě ACL jsou ještě rozšířené atributy (extended attributes - XATTR), o těch nevím v zásadě nic, k ukrytí souborů by se teoreticky použít daly, pokud by tato funkce byla doplněna. Více v attr(5). Připojovací parametr je user_xattr.

Zajímavé jsou ještě další atributy souboru, připojovací parametr je attrs a nástroj k jejich nastavení je chattr. Např. chattr +i nastaví neměnitelnost souboru či adresáře – soubor či adresář je pak přístupný pouze pro čtení i pro uživatele root, ovšem ten může příznak pomocí chattr -i zase odebrat. Ke skrývání souborů však nevede ani tento nástroj.

[frEon]

nutno dodat, ze chattr funguje pouze na ext3, ext2, na ext4 nevim a na ostatnich filesystemech ne.

[#Tom]

Já jsem se o chattr, zejména pak chattr +i dověděl až během používání ReiserFS3 a na něm jsem to zkoušel, takže přinejmenším nezměnitelnost (asi nejvýraznější funkce tohoto příkazu) funguje i na ReiserFS3.

[frEon]

root@neotronic-ntb:/# mkfs.reiserfs /dev/loop0
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
...
blablabla
...
ReiserFS is successfully created on /dev/loop0.
root@neotronic-ntb:/# mount /dev/loop0 /mnt/
root@neotronic-ntb:/# cd /mnt/
root@neotronic-ntb:/mnt# touch a
root@neotronic-ntb:/mnt# chattr +i a
chattr: Inappropriate ioctl for device while reading flags on a

U me to nefunguje, nejsou potreba nejake specialni volby pro mount?

[#Tom]

attrs

[frEon]

Diky

[Michal Kubeček]

lion:/home # mount | grep /home
/dev/md2 on /home type xfs (rw)
lion:/home # touch abc
lion:/home # chattr +i abc
lion:/home # lsattr abc
----i--------- abc
lion:/home # rm abc
rm: nelze odstranit „abc“: Operace není povolena
lion:/home # chattr -i abc
lion:/home # rm abc
lion:/home # ls -l abc
ls: nelze přistoupit k abc: není souborem ani adresářem

[frEon]

Ted jsem si to vyzkousel a mas pravdu. Dik. Kdysi jsem nekde cetl, ze to jde jen na ext2/3, kdyz jsem to zkusil u sebe na reiseru, tak mi to nefungovalo (viz vys), coz jsem bral jako potvrzeni.

[pasmen]

Klikátko pro ACL na Linuxu se jmenuje Eiciel (možná jedno z mnoha, nevím).

[Kyosuke]

Klikátko pro ACL na Linuxu se jmenuje Eiciel (možná jedno z mnoha, nevím).

Já mu teda říkám Konqueror.

[rastos]

Z akej verzie KDE?

[otula]

3.5.9 to umí určitě

[rastos]

A fakt. Len človek musí mať ten filesystém pripojený s voľbou acl. Pochopiteľne. Dik.

[podlesh]

Dokumentace je, hlavně v manuálových stránkách (acl, setfacl, getfacl) a asi i jinde (tu jsem ale nikdy nepotřeboval). Posixové a linuxové ACL jsou prostým rozšířením UNIX práv: umožňují klasickou trojici rxw přřazovat nejen klasické trojici ugw (user, group, other), ale libovolnému uživateli či skupině. Navíc je možné definovat defaultní práva pro adresář, která specifikují práva pro nově vyrobené vyrobeným soubory a adresáře (no, teď nevím zda jsem to napsal srozumitelně).

ACL nemá nic společného s viditelností souboru v různých programech.

[Heron]

Jenom doplním, že perfektní návod k ACL jsem našel v příručce k OpenSUSE.

[Kyosuke]

To se pěkně poslouchá. Děkujeme.

[thingie]

Postup vyhodnocování je v manu a to myslím celkem stačí.

[Kyosuke]

Ano, a man je taky zbytečný, protože to je i ve zdrojáku.

[thingie]

No, to je, ale myslím, že uvážím-li délku popisu, snadnost jeho nalezení a pochopení, tak v těchto parametrech z toho nejlépe vyjde ten man.

[Kyosuke]

Opravdu? Někdo si radši přečte pár čitelných vysvětlujících stránek v trošku lidsky vřelejší dokumentaci, než nakoukne do strohé reference (jejíž styl je samozřejmě naprosto v pořádku, ale jako výukový text pro obecnou populaci by to asi obecná populace nechtěla).

[David Jaša]

Man je fajn pro referenci k něčemu, o čem vím, že to existuje a co to dělá. K obecnějšímu seznámení s problematikou, kterou neznám se hodí víc právě ty příručky, knížky, články atd.

[pavlix]

Je k tomu někde nějaká dokumentace?

The ACL is a concept with several different implementations in various operating systems, although there is a POSIX "standard". (The POSIX security drafts, .1e and .2c, were withdrawn when it became clear their scope was too wide and the work would not complete, but the well-developed parts defining ACLs have been widely implemented and are known as "POSIX ACLs".)

~Wikipedia

[Michal Fecko]

JFS je velmi dobra volba...

[kotyz]

Taky sem o nem premejslel, ale mam malo informaci, hlavne me chybi ty stovky spokojenych uzivatelu co by ho vychvalovali ...

Mel by pro me smysl?

[andree]

ja neviem, ale ked sa pouzival na IBM mainframoch s aix-om, tak to nemoze byt zly filesystem.. par rokov ho uz pouzivam, a mam teda pocit ze sa pri fsck k suborom chova priatelskejsie ako xfs, a ze je aj rychlejsi ako ext3/xfs.. no.. ako ext3 urcite :)

[kotyz]

Ja to chci na desktop. XFS se taky pouziva na ruznejch vysokovynostnich masinach, ale aby mi to po vypadku proudu a fsck vynulovalo pulku/vsecky soubory to se mi hrube nelibi. JFS to prej nedela a presto je podobny XFS rychlosti a jinyma pozitivnima vlastnostma. A taky to byl vychozi fs v posledni verzi IBM OS/2 ktera vysla

[Michal Kubeček]

ale aby mi to po vypadku proudu a fsck vynulovalo pulku/vsecky soubory to se mi hrube nelibi

A vám už se něco takového stalo?

[kotyz]

Nikdy sem XFS nepouzival, ale lidi co ho pouzivali si na to casto stezujou. Spravne by tam melo bejt spis: vynulovalo pulku/vsecky soubory co byly zrovna v dobe vypadku otevreny pro zapis. Ale stejne ...

[Michal Kubeček]

Možná každý sledujeme jiné diskuse, ale co si pamatuji já, většinou si na to stěžují spíš lidé, kteří XFS nepoužívali, nepoužívají a ani to nemají v úmyslu…

[kotyz]

Protoze ty co ho pouzivaji sou na tohle pripraveny a maji pravidelny zalohy a UPSky. Nebo ne?

[Mandarinka]

FS který ode mě vyžaduje UPS a pravidelné zálohy nebudu věřit k zajištění základní bezpečnsoti. Ostatní nabízejí rozumnou úroveň jistoty (ve skutečnosti velmi vysokou, prakticky takovou, že záleží jen na poruše HW) i bez těchto opatření, takže mají přirozeně u mě přednost. Koneckonců [XFS' + zálohy + UPS] > [XFS + zálohy + UPS] :)

[happy barney]

hmm, existujú napr SCSI radiče s cache zálohovanou baterkou ..

[Kyosuke]

...a v hardwaru SGI mašin vedl od zdroje k procesoru přerušovací signál, který operační systém implementoval se sémantikou "všeho nech a zachraň metadata, jak nejrychleji můžeš!". PCčku by se něco takového dost možná taky hodilo, ale nezapomeňme, že je řeč o šrotarchitektuře. ;/

[kotyz]

XFS taky nebylo navrzeny na desktop. Tam, kde se obvykle nasazuje, tam se to vetsinou hemzi vice procesorama, vice pametma, scsi diskama v poli, zalohovacima paskama a zaloznima zdrojema. Viz tady (rok 1996).

[frEon]

Sgi strkalo xfs i do svych pracovnich stanic.

[Kyosuke]

...a jak píšu o něco výše, nebyli tak hloupí, aby se nepojistili, že při tom nedojde k průseru.

[kotyz]

Pracovni stanice neni obycejnej desktop. Tam bych taky ocekaval kvalitni hw a zalohovani (dat i napajeni). A ze se na ni bude hlavne pracovat a ne hrat a rejpat do toho ...

[andree]

mne ano, a moc som sa nesmial.. taku featuru mozno clovek oceni, ked ma zalohy a po resete si rychlo obnovi do konzistentneho stavu to, co ma nulovu dlzku - ale ked takto 'normalnemu, nie kazdu minutu zalohujucemu cloveku' zmizne par nahodnych suborov, tak to fakt nepotesi... navysie som si nie uplne isty, ci miznu iba subory otvorene pre zapis

a dalsi problem je, ze vacsina normalnych user desktopov sa neresetuje kvoli vypadku napajania, ale kvoli padu systemu (ovladace grafiky, zejo) - takze take ze "s xfs treba mat UPS" je vcelku nepouzitelna rada.. povedal by som ze dobra rada je "ak pouzivate stroj na vypocty, nepouzivate ziadne nestabilne ovladace a mate ups - pouzite xfs, inak nieco ine"...

[Mandarinka]

Ono hlavně ta nejistota - nejhorší po havárii, nebo nějaké chybě /a tyk napadení virem či dokonce hackem/ je, že nevíte, co máte kde porouchané. M8me na HD stovku projektů, na většině se nedělá, na některých ano, plus hromady fotek, a nikdo nemá moc přehled o tom, co se kdy změnilo... Navíc nemůžeme zálohovat každý den. I kdyby sme to dělali, za den se udělaá na docela dost souborech docela dost práce... takže jestli po mě někdo chce abych si rutině ověřoval, jestli se mi v nějakých souborech vyhlásila republika zeronie, tak ho posílám do UJ

[MJ]

Nejistoty se nezbavíte, tedy alespoň pokud pracujete na běžném PC-čkovém hardwaru, mezi jehož ctnosti rozhodně nepatří spolehlivé ukončení zápisu při výpadcích, ani dodržování předepsaného pořadí zápisů. Obojí způsobuje, že journalovací FS nezaručí integritu dat. Tyto problémy nejsou zrovna časté, ale občas se projeví, takže jistotu značně nahlodají.

[Mandarinka]

Jak říkám, v zásadě ostatní FS nabízejí rozumnou míru jistoty, zatímco XFS při stejné ivestici (tzn. nemám UPS :) nabízí jistotu o něco menší. Možná "rozumně" menší, co já vím, ale pro mě dostatečný důvod vybrat jinak. Stejně je to asi FS dělaný na pracovní oddíly (to místo, kde komprimujete video, nebo spíš stříháte, děláte iso a pak různé profesionální věci) a ne na dlouhodobě uložená data.

[Mandarinka]

A kdyby byla UPS (nebo na NB), tak bych sáhl zase jinam, protože by to opět bylo jistější.

[M. Lox]

Ano, JFS je velice stabilni. Dokonce jsem v životě neslyšel, že by s ním někdo ztratil data, narozdíl od jakéhokoliv jiného FS.

[Kyosuke]

Zde se v případě rovnice Počet uživatelů krát poruchovost rovná se nula může ale jednat o to, čemu se v matematice říká "triviální řešení".

[M. Lox]

Já ho používal několik let na OS/2, nikdy jsem s ním neměl problém. Po přechodu na Linux jsem přešel na Reiser4, se kterým jsem taky nikdy neměl problém . Takže máš v tomhle asi pravdu.

[David Jaša]

Nejedná, protože počet uživatelů je určitě větší nebo roven jedné.

[M. Lox]

JFS je fajn, akorát je docela pomalej.

[Michal Fecko]

JFS je fajn, akorát je docela pomalej.

pomaly v akych operaciach? citani? zapisovani? citani malych suborov? zapisovani velkych suborov?

[M. Lox]

Pomalej pri cteni a pri jakekoliv nesekvencni operaci. Pri sekvencnim zapise je docela rychlej a pri mazani je sice o hodne rychlejsi (alespon pri sekvencnim, nahodne je ale taky dobre), ale na tom na desktopech moc nezalezi. Vyhodou je pak nekolikanasobne mensi narocnost na CPU. Porovnavano s ext3, oproti Reiser4 je pomaly furt . Pouzity testy z bonnie++, soubory o 100 kB.

[Michal Fecko]

JFS @ Wikipedia

JFS is a 64-bit journaling filesystem created by IBM. It is available under the GNU GPL.
...
According to reviews and benchmarks of the available filesystems for Linux, JFS is fast and reliable, with consistently good performance under different kinds of load, contrary to other filesystems that seem to perform better under particular usage patterns, for instance with small or large files. Another characteristic often mentioned, is that it's light and efficient with available system resources and even heavy disk activity is realized with low CPU usage.

[alblaho]

Myslím, takhle nějak charakterizují JFS lidi, co si ho vybrali. V žádném ohledu není nijak zázračný, ale ani nemá žádnou nápadnou slabinu. To znamená, že je to opravdu dobrý FS.

Já jsem reiserista, ale vím, že jeho slabinou je dost dynamický layout (zfetovaný strom), který když se poškodí, může být zle. ExtX je naproti tomu takřka feudální záležitost, maximálně statický, což má zase jiné vady. Xfs není ideální na malé soubory a prej cachuje až příliš agresivně.

Vlastně slabinou JFS je jeho relativně malá uživatelská základna.

[Michal Fecko]

Vlastně slabinou JFS je jeho relativně malá uživatelská základna.

Mozno to je tiez vyhoda, tazko povedat...

[alblaho]

A v čem by ta výhoda měla spočívat? Já vidím jen míň testování, míň zkušeností - referencí, míň patchů.

[Michal Fecko]

A v čem by ta výhoda měla spočívat? Já vidím jen míň testování, míň zkušeností - referencí, míň patchů.

Brzdi V koľkých inštitúciach po svete (banky, školy, ...) používajú IBM mainframes? A aky FS tam je?

[Heron]

A jaký OS?

[Michal Fecko]

AIX, ale to nieje podstatne, podstatny je FS a ten je rovnaky!

[Heron]

To je tedy hodně podstatné. To, že je JFS odladěný na AIX neznamená, že bude i pro linux. Nemají stejné kernel API.

[M. Lox]

To je pravda – na OS/2 mi přišel JFS o něco rychlejší než na Linuxu. Taky tam pro něj bylo víc utilitek které nikdo nepřeportoval (asi je IBM neuvolnilo, nevím). Jedná se ale jenom o subjektivní pocit, podložené to nemám.

[ondrej]

ze som si to za tie tri roky pouzivania nevsimol...

[xm]

Tak s tím nemohu souhlasit. Z filesystemů, které jsem kdy používal na desktopu (ext3, reiserfs, jfs), se mi JFS jeví subjektivně jako nejrychlejší. Nejpomalejší mi vždy připadal ext3 (bez ohledu zda je zapnutý či vypnutý dir_index, vždy to byla pomalost sama).

[xm]

I když teď jsem se koukal na benchmark, který tu někdo odkazoval, a podle něj je opravdu JFS jedním z pomalejších filesystemů. Nicméně je mi to trochu divné, už jsem viděl jiné benchmarky, kde JFS dopadl podstatně lépe. A hlavně s JFS mám opravdu na desktopu zkušenost, že je s ním systém o poznání svižnější než třeba s ext3.

[otula]

S těmi benchmarky - namátkou třeba na tomto se to u ext3 červená prakticky nejvíce. Ta dobrá zkušenost s JFS by také ale mohla souviset i s tím, že má nízké nároky na procesor.

[alblaho]

No, ten benchmark je nad jádrem 2.6.0-test5.

[otula]

Jasně, byl to první test, který mi Google našel. Nic to ale nemění na tom, že JFS velmi málo zatěžuje CPU.

[M. Lox]

Jak jsem psal výše – na Linuxu mi přišel JFS o něco pomalejší než na OS/2. Když jsem k Linuxu přišel, začal jsem s JFS, protože už jsem s ním měl zkušenost, pak jsem zkoušel ext3, ten byl zhruba stejně rychlý, pak ReiserFS, ten byl o dost rychlejší, a pak Reiser4, který to vyhrál a tak u mně už zůstal.

[Michal Kubeček]

Řekl bych, že JFS trpí klasickým problémem vstupní bariéry. Málokdo ho používá, takže se o něm nemluví a nepíše. A protože se o něm nemluví a nepíše, málokdo se ho odváží použít…

[Michal Fecko]

Řekl bych, že JFS trpí klasickým problémem vstupní bariéry. Málokdo ho používá, takže se o něm nemluví a nepíše. A protože se o něm nemluví a nepíše, málokdo se ho odváží použít…

Presne! Strach z neznameho... To co nieje "mainframe" (ako ext3 - odhliadnuc od faktu ze ext3 nieje najlepsia volba, akurat najviac podporovana) je apriori zatracovane/odmietane...

[kotyz]

Nemelo by tam bejt spis "mainstream" ?

[Michal Fecko]

jj, chybycka sa vludila - mainstream samozrejme

[xm]

Připište si jednoho spokojeného uživatele JFS (jak na desktopech, tak na serverech)

[juice]

+1

[Non_E]

Používám ext3, jfs, xfs, reiser4 - každý většinou tam, kde se uplatní jeho výhody. O tom to podle mě je, ne?

[alfonz]

používám téměř výhradně reiserfs, bohužel ale ne 4, jelikož je jen na livkách s system rescue CD a kompilovat se mi nechce...je ho škoda, myslím, že tenhle systém by se uchytil...

[krab1k]

Zdá se mi to, nebo podle té ankety je tu zatím skoro 90 lidí, kteří by Reiser4 používali (nebo alespoň zkusili), pokud byl v hlavní větvi?

[kotyz]

Komu by se taky chtelo kvuli nemu kompilovat/patchovat jadro, ze?

Pro tu moznost sem hlasoval i ja.

[krab1k]

Tak já kernel v Gentoo kompiluju stejně. Teď jsem se díval a v openSUSE Build Service balíček s Reiser4 je pro verzi 11.0. Aleš výše nabídl vytvořit deb balíček. Nevím, jestli je tu někdo, kdo by to samé udělal pro Arch (mrknul jsem na profil). Třeba bychom tu podporu společně dali nějak dohromady.

[kotyz]

PKGBUILD bych udelat moh, ale chce se mi? Nechce. Moc prace a pak bych to stejne nepouzival, takze by to musel stejne testovat nekdo dalsi ...

[Aleš Kapica]

Ne že bych ho nabídnul vytvořit. Já je mám vytvořené. Jen nejsou umístěné v repository, kterou by bylo možné přidat do apt.

[krab1k]

Aha, jasně. Já jsem tím chtěl jen říct, že není zase takový problém Reiser4 do systému dostat. U mě na Gentoo to byla záležitost asi patnácti minut (včetně rekompilace kernelu a restartu PC).

[Michal Kubeček]

To je IMHO zkreslená interpretace. Spíš bych to viděl tak, že je tu 90 lidí, kteří ho určitě nenasadí na do ostrého provozu, dokud ve vanilla jádře nebude. To ale nutně (přinejmenším u jednoho z těch devadesáti) neznamená, že jakmile bude ve vanilla jádře, tak ho nasadí. Prostě pak jen bude připadat v úvahu společně s ext3, ReiserFS 3.6, XFS, JFS a možná i ext4.

[krab1k]

Když si to tak znovu čtu, tak uznávám, že to tak asi skutečně bude. Alespoň jsem v tom původním komentáři zahrnul i možnost, že by ho jen zkusili.

[Hynek (Pichi) Vychodil]

Vzhledem k tomu, že úplně chybí možnost "nepoužívám protože je mi Reiser4 úplně u prd...", tak se mohlo celkem dost lidí schovat do této kategorie i když by ho nepoužívali ani kdyby bylo ve vanilla.

[Luboš Doležel (Doli)]

Na ReiserFS (3.6) mám v poslední době problém při kompilaci některých hutnějších projektů. I když je priorita kompilátoru minimální, při práci s velkým množstvím souborům se až na 5 minut zasekne systém se šíleným loadem (přes 25) a diskovou aktivitou. Podle time je to aktivita v jádře. Nedostatkem RAM to není.

Takže si říkám, že je možná čas zkusit něco jiného.

[alblaho]

Upřímně řečeno, 5 minutový zásek je dost podezřelý a vinit z toho zrovna lety prověřený ReiserFS... Krom toho malé soubory by měly být jeho silnou stránkou.

Je v pořádku ten disk?

[Luboš Doležel (Doli)]

Disk je v pořádku a dělá mi to i kromě jednoho desktopu i notebook... jde o kompilaci věcí jako Boost. V moment, kdy to začne načítat hodně dat, je mrtvo. Zkusím JFS.

[alblaho]

Já jsem na svém ReiserFS překládal kde co (gnome, pypy, jádro) a nikdy jsem neměl pocit, že by mě brzdil filesystém.

Ale Boost možná bude jiné kafe, protože překládat divoké šablonování je masakr. Ale stejně by to neměl brzdit FS. Jdu to zkusit.

[alblaho]

Tak jsem si přeložil Boost aniž bych cokoliv zpozoroval. Ubuntu, ReiserFS, dva roky starý notebook s gigem paměti.

Kolega dole to vidí na IO scheduler. Ale rozsekneš to jedině tak, že si inkriminovaný projekt přeložíš na jiném FS.

[Mandarinka]

Není to spíše způsobeno špatným schedulováním I/O operací? Známá věc z WinXP - CPU máte nevytížené, nebo vytížené aplikací s nízkou prioritou (takže za normálních podmínek by jste měly prakticky stejnou responzivitu a čas CPU), jenže někdo začně žrát z disku a jste v čoudu, protože plánovač CPU nebere ohled na I/O - a byť máte k dispozici dost CPU, začnete se sekat, protože nemáte včas data a i operace s RAM mohou mít vzrostlou latenci...

Abych to shrnul, podle mě nebude problem s FS, ale se schedulerem I/O.

[Luboš Doležel (Doli)]

To by mohlo být ono. Zkusím JFS a uvidím.

[MJ]

Krom toho malé soubory by měly být jeho silnou stránkou.

Co se prostoru týče, tak rozhodně. Co do času, netoliko.

Mně osobně jako hlavní problém Reiser3 a zčásti také Reiser4 přijde neexistence spolehlivého fsck. Reiser3 chodí hezky do okamžiku, než se něco rozbije, a pak už ho je opravdu těžké dát dohromady.

[Aleš Kapica]

Ale? Nepovídejte? Většinou jsem byl úspěšnější než kolegové u ext3.

[MJ]

Už jsem opravoval i hodně poničené ext3fs a vždy se podařilo dát nějak data dohromady (byť párkrát muselo pomoci debugfs), u Reiser3 obvykle fsck filesystem ještě víc poničilo.

(Jinak aby bylo jasno: mluvím o takových chybách jako nečitelná či přepsaná část disku nebo špatný kontakt na kabelu, který způsobil, že polovina zapsaných sektorů měla bit 15 v každém slově nulový. Triviality typu crash při zápisu zachrání journal.)

[M. Lox]

Reiser4 má fsck IMHO velmi podařený. S RFS3 jsem nepřišel moc do styku, tak nevím.

[Petr Tomášek]

V anketě mi chybí volby:

• nepoužívám ho, protože používám něco jiného
• nepoužívám ho, protože nemám čas na experimenty
• nepoužívám ho, protože pařez
• no prostě ho nepoužívám, co je na tom s*kra špatně?

[mimi.vx]

+1 , jde mimo koncepci jadra + po celou dobu tradice spatna komunikace s hanse,

[Aleš Kapica]

Pokud vím, tak mimo koncepci jádra jde především tím, že používá pluginy. V tom však nevidím apriori nic špatného. A pokud jde o komunikaci. No nevím, ale mě osobně by asi docela prudilo kdyby někdo pernamentně svévolně upravoval můj kód, poškozoval tím jeho funkčnost a pak to použil ještě jako argument že je vadný.

[trekker.dk]

Máš to trochu přehozené - kód je vadný, proto je upravován, načež je dál vadný...

[M. Lox]

Mně osobně teda patche od Šiškina fungují výborně, zatímco -mm verze ne.

[Aleš Kapica]

Přehozené to máš ty a dost. Protože nahrazovat funkce funkcemi zcela jinak fungujícími jen proto, že mají podobný název a nazývat to drobnou úpravou, může jen magor. Originální patch funguje naprosto bez problémů.

[Mandarinka]

Dost škoda. Já bych ho bral, halvně bych bral transparentní kompresi, nejlépe v kombianci s tail packingem - an uložené webové stránky (a bodobyný bordel kde nezáleží na výkonu) by to bylo super. NTFS bohužel komprimované soubory nemůže zapisovat přímo do MFT (normálně tam může zapsat malé soubory soubory někdy, až o 800bytech...).

[nhy]

Dnes s uvaznenym Reiserom uz Reiser4 nema buducnost. Buducnost je v ZFS, ktory dnes uz na linuxe nie je problem cez FUSE pouzivat.

[Michal Fecko]

Az na to ze nieje v kerneli a FUSE nieje to prave orechove

One solution to this problem is to port ZFS to Linux's FUSE system so the filesystem runs in userspace instead

a ma komplikacie s licenciami.

Porting ZFS to Linux is complicated by the fact that the GNU General Public License, which governs the Linux kernel, prohibits linking with code under certain licenses, such as CDDL, the license ZFS is released under.

... a ma aj svoje limity...

[M. Lox]

…a je dost pomalej a duplikuje vlastnosti, které se dají najít jinde (to druhé mně osobně nevadí, ale jedná se o jeden z důvodů, kvůli kterým nebyl přijat Reiser4, takže doufám, že nevezmou ani ZFS) a které většinou stejně na desktopu nemají využití.

[kotyz]

Nepresel uz OpenSolaris na GPLv3? Myslim si ze snad i jo ...

V tom pripade by problemy s licencema byly ze hry.

[Luboš Doležel (Doli)]

Nebyly, jádro je GPLv2.

[kotyz]

Tak by preslo pod GPLv3, o tom uz se taky uvazovalo (a mohlo by to bejt pruchozi) ...

[Luboš Doležel (Doli)]

Kvůli ZFS by asi nepřešlo

[Ladicek]

Myslím, že se Linus zmiňoval, že právě kvůli ZFS pod GPLv3 by byl ochotný se snažit o přelicencování jádra Ale o tom, že by OpenSolaris už byl pod GPL, teda slyším prvně, to mi asi něco uniklo…?

[kotyz]

Nektery casti urcite, ale jestli celej to nevim. Neco bude asi porad pod CDDL. Javu uz taky otevreli (az na naky nepatrny % kodu).

[kotyz]

Za moznost vykradat solaris by to stalo -> ZFS, Dtrace a dalsi zajimavy veci. V BSD a Mac OS X uz maji oboji naportovany.

[MJ]

A co je vlastně na ZFS tak úžasného, co by neměla ext4?

[M. Lox]

Online zvětšování/zmenšování oddílů, RAID a všechna podobná funkcionalita LVM, snapshoty, copy-on-write… Pro servery skvělé, na desktopech spíš vynikne jeho malá rychlost.

[Mandarinka]

Hezky řečeno:) A taky velká spotřeba RAM.

[MJ]

Online zvětšování má už ext3, jak se to se zmenšováním, nejsem si úplně jistý, ale myslím, že ext4 ho už má také.

RAID a spol. jsou spíše chybou, takové věci přeci nemají co dělat ve filesystemu! Jen dobře, že jsou v LVM a mohou sloužit pro všechny FS.

Snapshoty by měly s kombinací ext4+LVM měly fungovat také, takže zbývá copy-on-write a ten mi nepřide tak užitečný, aby vyvážil daleko větší režii ZFS.

[M. Lox]

S tím RAIDem nemáš tak úplně pravdu – takhle můžeš distribuovat soubory inteligentně, tedy že soubor menší než velikost stripu u RAIDu 0 bude vždy jenom na jednom disku nebo že se samotná struktura FS nebude distribuovat a do RAIDu půjdou jenom data, což zvýší odolnost proti chybám apod.

[MJ]

Na to přeci úplně stačí, aby uměl FS s LVM spolupracovat, určitě není potřeba ho s ním skřížit

[Ondrej 'SanTiago' Zajicek]

Je ale otazka, zda pri tak vyrazne urovni spoluprace vubec z toho LVM neco zbyde. Jinymi slovy, pokud FS si nevystaci s predpokladem, ze je na jednom blokovem zarizeni s uniformnimi parametry (ktere by mu zajistilo LVM) a bude chtit implementovat featury, pro ktere musi znat strukturu uloziste (napriklad mit RAID 1 pro metadata a vybrana data, RAID 5 pro ostatni data, nebo treba mit filesystem pres vic disku udelany tak, ze jednotlive soubory jsou na jednom disku a pri vypadku jednoho disku je mozne filesystem stale pouzivat, ale dostupne budou jen soubory na funkcnim disku), zda neni jednodussi mit rozhrani takove, ze ma k dispozici n blokovych zarizeni, nez ze ma k dispozici jedno blokove zarizeni a sofistikovany system pro zjisteni jeho struktury.

[JS]

V takovem pripade ma LVM stale tu vyhodu, ze i FS, ktere predpokladaji uniformni zarizeni nepredpokladaji, s nim stale budou fungovat.

[MJ]

Myslím, že i tak to má smysl, a to hned z několika důvodů:

1. LVM má jednotné ovládání a funguje se všemi FS. Proč by se u jednoho FS takové věci měly ovládat jinak?
2. Filesystemů, které si budou chtít s LVM povídat, nejspíš bude časem přibývat.
3. Když si vymyslím nový druh redundance (třeba takový, který snese výpadek až K disků pro libovolné zadané K, nebo který bude umět opravovat i chyby v datech, nejen výpadky), nechci ho implementovat vícekrát.
4. Podobně pro akceleraci existujících RAIDů. Už teď kernel používá několik různých funkcí na XORování bloků a vybírá si podle typu CPU ten nejrychlejší. Podobně může existovat HW akcelerace. Toto všechno je lepší implementovat centrálně v LVM.

[Ondrej 'SanTiago' Zajicek]

1. Pokud budu chtit nastavovat nejake filesystem-specific parametry, ktere by byly nutne k takove konfiguraci, tak krome jednotneho toolu pro LVM budu muset jeste zavolat specificky tool pro filesystem a obema zadat konzistentni hodnoty, jinak to bude zlobit. To uz je snad lepsi varianta, kdyz staci pouzit filesystem specificky tool, ktery si sam interne nastavi i LVM funkcionalitu. Koneckoncu - tohle je i v soucasne dobe, kdy krome nastaveni LVM je treba rucne zvetsit/zmensit filesystemy, ale to ma aspon tu vyhodu, ze u vsech filesystemu je jeden jasny parametr, takze by to mohlo byt delane opacne - obecny LVM tool interne zavola specificke FS tooly.

3. Problem je, ze muzu chtit implementovat druh redundance, ktery vyuziva (filesystem-dependent) informace z vyssich vrstev. Napriklad MD5 soucty filesystemovych struktur a souboru. Neco takoveho dost dobre neimplementuju v nizsi vrstve a portabilne.

4. Neni neco takoveho lepsi implementovat v nejake obecne XORovaci jednotce, nezavisle na jejim uziti? Jinak nemylim-li se, tak LVM v soucasne dobe stejne neumi pouzit hardwarove akcelerovane RAID radice.

Mimochodem, prirozeny pozadavek na funkcionalitu by mohl byt takovyhle - filesystemy FA, FB, FC sdili disky DA, DB, DC, DD. Kazdy z filesystemu ma vyhrazene nejake misto, ale zbyvajici misto sdili podle potreby (a s ohledem na granularitu). Tohle asi se stavajicim LVM nejde udelat, neni-liz pravda? Pritom do mnoha filesystemu ani do samotneho LVM by to nemusel byt problem dodelat, ale musel by se zmenit koncept interface mezi LVM a FS z 'tady mas virtualni partition a hrej si' na 'alokuju blok/vracim blok'.

[M. Lox]

Taky pravda. Já jsem s LVM nikdy nepracoval, takže moc nevím, co všechno to umí. ZFS jsem chvíli testoval, ale je to utrpení. Jako šnek.

[Michal Vyskočil]

Ta mediální masáž Sunu? Marketing jim docela jde (viz Java).

[Let_Me_Be]

Hmm, opravdu nevim, ale od doby, kdy je v jadre XFS a JFS nevidim duvod pouzivat Reiser. Ma proti nim nejake dobre funkce?

[Aleš Kapica]

Nevím jak JFS (nepoužívám) ale použití XFS je bez záložního zdroje pokud vím koleda o ztrátu dat.

[Let_Me_Be]

Ja pouzivam JFS prave kvuli skvele obnove po vypadku. Ale ani s XFS jsem nemel moc problemy (i kdyz jo, jednou jsem skoro prisel o cely filesystem).

[kotyz]

To je vlastnost XFS, ma to svy duvody (ale ted sem linej dohledavat jaky). XFS urcite neni 'designed for desktop use'.

[Kyosuke]

Někde jsem na téma XFS a výpadky proudu viděl od jednoho příznivce XFS krásnou poznámku, která zněla asi jako "Komponenta zodpovědná za spolehlivé napájení počítače se nenazývá 'souborový systém'".

[kotyz]

U me se komponenta zodpovedna za vypadky jmenuje 'dedek kutil elektrikar ve vysluzbe'. Vyhodit hlavni jistic pro nej neni problem a to si nemusi ani preseknout kabel svoji na kolene delanou dvoumotorovou sekackou na 380 V, staci neco mensiho ...

[andree]

len je blbe, ako som uz vyssie pisal, ze stabilne napajanie nie je jediny problem desktopov...

[trekker.dk]

Kdežto pro Reiser platí to samé...

[#Tom]

Moje zkušenosti jsou podobné. Ale zatímco XFS se podělal po několika výpadcích systému (především kvůli napájení) a vesele si kernel-panicoval kvůli poškození souborového systému (mimochodem neochota xfschecku kontrolovat kořen připojený jen pro čtení mi taky dost vadila), ReiserFS3 se s takovým krutým zacházením spokojil po tři roky, než se rozbil (některé soubory a adresáře se měnily dočasně na nečitelné), nicméně všechno se mi nakonec povedlo zachránit a po nové instalaci pracuje ReiserFS3 zase k mé plné spokojenosti.

[M. Lox]

Atomické transakce, žurnálování dat, mnohem vyšší výkon zejména s malými soubory, transparentní inteligentní komprese, výborné využívání volného místa…

[MJ]

Pokud vím, tak poslední pokus o začlenění Reiser4 do jádra skončil zjištěním, že tento filesystem má fatální chyby v zamykání. Pokud to ještě nikdo neopravil, tak za nepřítomností Reiser4 v jádru, jakož i za tím, že mnoho lidí s tímto FS nechce mít nic společného, nejsou žádné podivné antipatie, nýbrž solidní technické důvody.

[M. Lox]

To je zajímavé, není k tomu nějaký odkaz? IMHO se všichni vymlouvali na to, že tam není, protože pluginy jsou špatné, protože jsou špatné, protože jsou špatné…

[MJ]

Odkaz přímo nemám, ale zkuste zalovit v archivu LKML.

Chyby v zámcích byly, pokud vím, hlavně v okolí pluginů a byly způsobené tím, že jeden objekt se mohl chovat jak jako soubor, tak jako adresář, s čímž architektura VFS nepočítá (a což také pravděpodobně odporuje POSIXu).

Jinak na pluginech je špatná jedna dost evidentní věc: to, že jsou specifické pro konkrétní FS, místo aby byly připojené do VFS. Nikdo moc nestojí o transparentní kompresi, která funguje jen s konkrétním FS, když přitom není výrazně těžší udělat ji obecnou pro všechny FS.

[M. Lox]

Jinak na pluginech je špatná jedna dost evidentní věc: to, že jsou specifické pro konkrétní FS, místo aby byly připojené do VFS. Nikdo moc nestojí o transparentní kompresi, která funguje jen s konkrétním FS, když přitom není výrazně těžší udělat ji obecnou pro všechny FS.

Tak to vysvětlím ještě jednou:

1. Reiser4 sám o sobě je jenom kostra, na kterou se lepí pluginy. Nemá specifikovaný ani formát, i ty B* stromy, silná stránka R4, jsou ve skutečnosti jenom záležitost reg40, Unix-file regular file pluginu.
2. Kvůli tomu se pluginy z R4 nedají vyřadit.
3. Kvůli tomu se ani nedají zahrnout do VFS – např. ten ccreg40 (Cryptcompress regular file plugin) vám neumožní kompresi pro celý FS, jako by tomu bylo ve VFS, ale pro jednotlivé soubory, každý zvlášť. Navíc z toho můžete libovolné soubory vynechat a navíc se automaticky ověřuje kompresní poměr, a při příliš nízkém se to samo vypne (a tím i zrychlí). To ve VFS nemůžete udělat ani náhodou a ani se to nedá portovat do jiného FS. Stejně tak máte i jiné pluginy – pro adresáře, pro žurnál, pro tail-packing, pro symlinky. Ty by taky měly být ve VFS?

BTW na LKML jsem našel jenom několik dlouhých diskuzí o tom, že má R4 nečitelný kód, ale nikdo tam (kupodivu) neřekl, v čem přesně je ten kód špatný.
A nakonec to, že se jeden objekt dá považovat za soubor i adresář je obrovská výhoda R4. Už jenom kvůli ní bych ho rád viděl ve vanilce.

[MJ]

Kvůli tomu se ani nedají zahrnout do VFS – např. ten ccreg40 (Cryptcompress regular file plugin) vám neumožní kompresi pro celý FS, jako by tomu bylo ve VFS, ale pro jednotlivé soubory, každý zvlášť. Navíc z toho můžete libovolné soubory vynechat a navíc se automaticky ověřuje kompresní poměr, a při příliš nízkém se to samo vypne (a tím i zrychlí). To ve VFS nemůžete udělat ani náhodou a ani se to nedá portovat do jiného FS.

Samozřejmě, že to ve VFS udělat mohu, jen pak musí jednotlivé FS trochu spolupracovat.

Například zapnutí komprese nebo šifrování pro jednotlivé soubory lze řešit úplně normálními extended atributy.

Stejně tak máte i jiné pluginy – pro adresáře, pro žurnál, pro tail-packing, pro symlinky. Ty by taky měly být ve VFS?

Ne nutně všechny, jen ty, u nichž to dává smysl. Ale komprese mezi ně jistě patří.

A nakonec to, že se jeden objekt dá považovat za soubor i adresář je obrovská výhoda R4.

A co je na tom tak třeskutě výhodné?

Já to naopak vidím jako dost zásadní problém. To, že objekty jsou buďto soubory XOR adresáře, je prostě ve všech Unixových programech tak hluboko zakořeněný předpoklad, že je těžké na něm cokoliv měnit. Pokud vyrobíte soubdresáře, rozbijete tím příliš mnoho věcí.

[M. Lox]

Výhodné je na tom např. to, že můžete mít atributy a metadata souboru uložená v jeho složce jako plaintext (něco jako procfs ), což práci s nimi hodně usnadňuje. Nebo mít k souboru komentáře. U Macintoshů to funguje i v POSIXu, Reiser4 je taky POSIX-compilant.

[MJ]

Výhodné je na tom např. to, že můžete mít atributy a metadata souboru uložená v jeho složce jako plaintext (něco jako procfs ), což práci s nimi hodně usnadňuje. Nebo mít k souboru komentáře.

Na to ale nepotřebujete chovat podvraťáky, můžete třeba nadefinovat, že k souboru /a/b/c existuje adresář /meta/a/b/c nebo /a/b/.meta/c.

U Macintoshů to funguje i v POSIXu, Reiser4 je taky POSIX-compilant.

O tom, že by byl Reiser4 POSIX-compliant, slyším poprvé. Dokážete například zařídit, aby se na něm choval konsistentně stat()?

[M. Lox]

Výhodné je na tom např. to, že můžete mít atributy a metadata souboru uložená v jeho složce jako plaintext (něco jako procfs ), což práci s nimi hodně usnadňuje. Nebo mít k souboru komentáře.

Na to ale nepotřebujete chovat podvraťáky, můžete třeba nadefinovat, že k souboru /a/b/c existuje adresář /meta/a/b/c nebo /a/b/.meta/c.

Nebo můžete mít databázi jako složku. To je IMHO dost užitečné a takhle to neobejdete.

U Macintoshů to funguje i v POSIXu, Reiser4 je taky POSIX-compilant.

O tom, že by byl Reiser4 POSIX-compliant, slyším poprvé. Dokážete například zařídit, aby se na něm choval konsistentně stat()?

Tak po rychlém vyhledání v mých e-mailech jsem zjistil, že v tomhle máte pravdu. Měl jsem za to, že to už opravili, ale to jenom Šiškin psal, že se na tom pracuje, ale nemá to moc velikou prioritu. Omlouvám se, nemám si číst mailing-listy o půlnoci.

[MJ]

Nebo můžete mít databázi jako složku. To je IMHO dost užitečné a takhle to neobejdete.

Tohle je spíš pěkný příklad toho, na co se souboroadresář doopravdy nehodí: Na vnitřní strukturu databáze, nebo obecně souboru, se často dává smysl dívat mnoha různými způsoby a nemá smysl jeden konkrétní preferovat. Spíš by se hodil nějaký způsob, jak si objednat konkrétní interpretaci. Třeba: "odgzipuj, z taru vytáhni konkrétní soubor a ukaž mi po položkách databázi v něm uloženou". To se ale už blížíme spíš ke Gnome-VFS. Každopádně taková věc nemá co dělat v kernelu.

[M. Lox]

No, to je konečně aspoň jedna dobrá poznámka.

[M. Lox]

Ha, zapomněl jsem na tohle:

Samozřejmě, že to ve VFS udělat mohu, jen pak musí jednotlivé FS trochu spolupracovat.
…
Ne nutně všechny, jen ty, u nichž to dává smysl. Ale komprese mezi ně jistě patří.

VFS umožňuje nějak jednoduše, přenositelně a elegantně řešit věci na úrovni jednotlivých souborů? Já tuhle problematiku nijak nestudoval, takže o tom nemám ponětí, ale měl jsem za to, že jenom umožní vložit další vrstvu nad nebo pod stávající FS, která s ním v podstatě nespolupracuje, takže v případě komprese by např. ext3 dostal už zakomprimované soubory, aniž by věděl, co je uvnitř – v metadatech by pak měl třeba zapsanou jinou velikost.

[MJ]

A proč by vlastně ext3 měla vědět, co je uvnitř?

V meta-datech by mělo být uložené to, co je na disku, čili zkomprimovaná velikost. Původní velikost můžete snadno uložit do extended atributu.

[M. Lox]

No jo. Já už jsem tak zblblej těma resource fork, data fork, že mi hned nedošlo, že ty extended attrs. se nemusí taky komprimovat. Zase moje chyba.

[Ondrej 'SanTiago' Zajicek]

A onen VFS modul by implementoval velikost ve fstat() pomoci cteni toho extended atributu?

[MJ]

Přesně tak.

[trekker.dk]

BTW na LKML jsem našel jenom několik dlouhých diskuzí o tom, že má R4 nečitelný kód, ale nikdo tam (kupodivu) neřekl, v čem přesně je ten kód špatný.

Jestli to nebude mít nějakou souvislost s tím, že když někdo tvrdí, že kód je nečitelný, tak ho potom nečte...

[M. Lox]

Ale Hans Reiser se ptal (!, to je skoro zázrak) na to, které úseky kódu jsou nečitelné a jak to zlepšit, a odpověď už nepřišla. Takže: Přepiš to, a nám se to možná bude líbit, ale spíš ne, protože ani pořádně nevíš, co máš přepsat.
Já vím, že Hansův styl psaní je trochu zvláštní, ale většina těch zdrojáků je vcelku dobrá a dá se v nich orientovat.

[trekker.dk]

Ale Hans Reiser se ptal na to, které úseky kódu jsou nečitelné a jak to zlepšit, a odpověď už nepřišla.

To se ani nedivím. Když se tady v Poradně objeví otázka, na kterou se dá odpovědět jednoduchým pohledem do manuálu, tak taky neodpovídám. V tomhle případě je dotyčný manuál Documentation/CodingStyle.

[M. Lox]

Coding style is very personal, and I won't _force_ my views on anybody, but this is what goes for anything that I have to be able to maintain, and I'd prefer it for most other things too.

To všechno vysvětluje. Není vyžadováno, ačkoliv mě potěší, a pak je vyžadováno…
Já chápu, že když tě někdo naštve tak, jak to Hans umí, tak jeho kód nevezmeš, ale proč se schovávat za takové kraviny, ať si to vyříkaj jako chlapi a pak ať ten kód přijmou

[trekker.dk]

Jestli náhodou ta část, kterou cituješ, nebude hodně stará a tudíž už ne aktuální - dodržování CodingStyle je vyžadováno už dost dlouho. Můžeš poslat patch.

Já chápu, že když tě někdo naštve tak, jak to Hans umí, tak jeho kód nevezmeš, ale proč se schovávat za takové kraviny, ať si to vyříkaj jako chlapi a pak ať ten kód přijmou

Jo, to už tu taky bylo. V souvislosti s Reiser4 je zmiňováno několik problémů (styl kódu, chyby,...) - přesto pokaždé příznivci tohoto FS "vyřeší" jeden z nich a tvrdí, že začlenění již nic nestojí v cestě. I když bude kód přehledný, stále je tu ta záležitost ohledně deadlocků na velkých systémech.

[pavlix]

Také vás tak unavují ty věčné hádky která distribuce je nejlepší nebo který OS je nejlepší?

Nebo který filesystém? Tebe to zřejmě zase až tak neunavuje :).

[Aleš Kapica]

Ale jo. Proto jsem přihodil tu anketu. Velice pěkně demonstruje jak je taktika Reiserových odpůrců účinná. Vůbec nejúděsnější mi přijdou 4% těch co odmítají tento souborový systém jen proto že jeho tvůrce řešil svou životní situaci zločinem. Zavrhovat apriori něčí práci kvůli jeho osobnímu selhání, mi přijde úchylné.

[happy barney]

ad anketa: chýbajú tam možnosti (v diskusii spomínané).
ad 4% ... no, súčet je >100%, mal si dať jednu možnosť, nie viacero

[MJ]

Nepatřím mezi na 4%, ale vlastně tento názor docela chápu – když jediný člověk, který je schopen daný filesystem udržovat a hlavně v něm opravovat chyby, skončí ve vězení, není situace zrovna růžová.

[Aleš Kapica]

Myslím si, že kdyby byl reiser4 zařazen do hlavní větve jádra, tak by se našlo docela dost lidí co by se o opravu případných chyb postaralo. Nikde není řečeno, že by se měl Reiser o tento souborový systém starat na věky věků.

[MJ]

A proč se tedy nikdo nemá k tomu, aby chyby v ReiserFS, které tomu začlenění brání, opravil?

[Aleš Kapica]

Protože tím co je příčinou toho, že reiser4 (nikoliv reiserfs!) není začleněn do hlavní větve jádra nejsou chyby. Jedna věc je tento souborový systém používat a oznamovat případné chyby. Druhá věc sledovat vývoj jádra a jeho změny reflektovat do kódu. Nicméně patch pro reiser4 jádra 2.6.25 lze použít i u nově vydaného jádra 2.5.26.

[anicka]

není začleněn do hlavní větve jádra nejsou chyby.

To jsou mi ale novinky...

[MJ]

Protože tím co je příčinou toho, že reiser4 (nikoliv reiserfs!) není začleněn do hlavní větve jádra nejsou chyby.

Ale, a na to jste přišel kde?

[trekker.dk]

Protože tím co je příčinou toho, že reiser4 (nikoliv reiserfs!) není začleněn do hlavní větve jádra nejsou chyby.

No jasně, že ne. Příčinou jsou ti zlí vývojáři, kteří se už od začátku rozhodli, že Reiser4 nechtějí, protože se jim nelíbila ta čtyřka v názvu...

[anicka]

Myslím si, že kdyby byl reiser4 zařazen do hlavní větve jádra, tak by se našlo docela dost lidí co by se o opravu případných chyb postaralo.

To určitě ano. Ovšem nejdřív by opravdu musel reiser vypadat tak, aby ho do kernelu někdo byl ochotný zařadit. Protože zatímco se určitě najde spousta lidí ochotných spravovat drobnosti a udržovat kód, těžko najdeš někoho, kdo bude ochotný to překopávat nějak víc. Což si myslím, že platí zrovna u reiseru ještě víc než obecně, kusy jeho kódu mi chodí na mailovou konferenci s vtipy

Přístup "dejme to do kernelu, tam to někdo spraví" přece nemůže fungovat - pokud je to rozbité, tak to v kernelu prostě nemá co dělat. Jestli je někdo doopravdy ochotný to spravit, stejně bude potřebovat silnější motivaci než fakt, že je to v kernelu. Navíc, kdyby tohle udělali s každým kusem kódu, brzy bychom neměli kernel, ale bordel.

[Aleš Kapica]

Chyba je podle mne něco co způsobuje nefunkčnost. Nic takového nepozoruji. Hovořil jsem o opravě chyb, které by se případně objevily v budoucnu. Pokud někdo shledává něco vtipného na způsobu zápisu kódu, tak mu to neberu. Pro mne je však rozhodující funkčnost. Krásně napsaný, ovšem nefunkční kód si můžete strčit někam..

[MJ]

Chyby, které způsobují nefunkčnost, v Reiser4 evidentně jsou. To, že se na Vašem stroji projevují s tak malou pravděpodobností, neznamená, že nejsou. Kdybyste měl 32-procesorový stroj, možná byste říkal něco jiného

[Aleš Kapica]

Používám i 32 bitový fyzický stroj, nejenom virtuály.

[M. Lox]

Bit a procesor jsou dvě odlišné věci

[MJ]

Já říkal 32-procesorový )

[Aleš Kapica]

O pardon.. Všiml jsem si až dodatečně že řeč je o 32 procesorech. Tak takový stroj jsem opravdu v rukou ještě neměl. Na omluvu smekám..

[Aleš Kapica]

Nicméně až najdu někoho kdo mi takový stroj na hraní koupí, milerád na něm Reiser4 otestuju

[anicka]

Nebude tak těžké sehnat práci, kde se k takové věci dostanete a budeme si s ní moct chvilku hrát... stačí chtít

[Aleš Kapica]

Mám to brát jako výzvu? Mimochodem by mě docela zajímalo kolik ze zdejších čtenářů si na takový stroj alespoň sáhlo.

[Aleš Kapica]

Já jsem teda zatím viděl nejvíc 8 tučňáků.

[Ondrej 'SanTiago' Zajicek]

Osmiprocesorovy stroj je taky neco, co je mozne dneska bezne koupit za par korun v Alze nebo CzechComputer.

[cthulhu]

nevim jak u konkurence ale momentalne nejvyssi rada od Sunu ma (zatim) max. 144 jader (2 x 9 desek x 4 CPU sokety x 2 jadra) a ne, na hrani vam to fakt nikdo nekoupi

[M. Lox]

Tak zase: víc informací by nebylo?

[MJ]

Račte prominout, ale hledat v archivech LKML za Vás opravdu nebudu.

[M. Lox]

Takže takový problém vlastně neexistuje a vy jste si ho tu právě vymyslel. To je vše, co jsem chtěl vědět.

[anicka]

Ne, to jenom znamená, že má MJ na práci i jiné věci než prohledávat archiv mailing listů, kde proletí stovky mailů denně - například číst ty dnešní maily

Víte, už jsme dospělí a vždycky nám všechno nepřistane pod nosem jen tak. Možná byste mě ale přemluvil, abych Vám to našla, když mi zaplatíte tak pět hodin práce - mít čas na čtení archivů by bylo fajn

[MJ]

Tedy jsem si asi vymyslel i Vás, takže neexistujete, a proto zmizte

[Aleš Kapica]

Tohle mi nepřijde jako věcný argument.

[MJ]

Ne, spíš takové naťuknutí pana Loxe, že jeho argumenty také věcné nejsou.

[M. Lox]

Moje argumenty jsou něco ve stylu presumpce neviny – dokud mi neukážete, že je tam chyba, budu to brát tak, že tam není. Na LKML jsem hledáním téhle chyby strávil patnáct minut, naprosto bez výsledku. Ale jinak by mi stačilo i nakopnutí k tomu, v čem se má na multiprocesorových strojích chovat divně, nemusí dávat odkaz. (třeba si ukládá počet procesorů na disk do čísla, které má vyhrazený čtyřbitový prostor a po přidání 17. procesoru to přeteče rovnou do metadat )

[MJ]

Inu, ta diskuse trvala několik týdnů a nastřádalo se v ní minimálně několik stovek mailů, takže je trochu bláhové domnívat se, že v ní za čtvrt hodiny půjde najít to podstatné. (Proto se mi také nechtělo Vám příslušné příspěvky hledat.)

Problémy na MP strojích byly, pokud vím, hlavně deadlocky. VFS má poměrně složitá zamykací pravidla, která jsou odlišná pro soubory a pro adresáře a pokud se k jednomu objektu budete v jednom procesu chovat jako k souboru a v jiném jako k adresáři, může snadno nastat deadlock. Detaily si už ale nepamatuji.

Jinak co se týče presumpce neviny, v kernelu platí trošku jiná pravidla: Kód není přijat do té doby, než ho někdo zkontroluje a shledá solidním. Minimálně jedno důkladné review Reiser4 se v oné době konalo a jeho výsledkem byla hromada nalezených chyb. Pokud vím, stále se čeká na to, až tyto chyby někdo opraví a někdo ho znovu zkontroluje.

[M. Lox]

To o té presumpci neviny se týkalo vašeho příspěvku, ne zahrnutí patchů do upstreamu, tam to samozřejmě chápu.

[thingie]

Já nevím jak u vás, ale tady preferuju postup „dokaž, že to funguje“ a ne opačný, který by mi přišel, no… hodně ujetý.

[M. Lox]

Jasně, ale ono to funguje, což jsem si už dokázal já sám. On tvrdí, že to fungovat nemusí, ale já nevidím důvod proč by nemělo, takže chci, aby mi to dokázal zase on.

[M. Lox]

Viz. „Dokaž, že je každá planeta (zhruba) kulatá.“ Já vím, že Jupiter a Mars jsou, protože je můžu vidět teleskopem. On tvrdí, že Země není. Já nevím proč ne, když všechny ostatní planety ano. Důkaz by měl provést on, protože jeho tvrzení se vymyká pravidlu, zatímco moje ho potvrzuje.

[MJ]

Myslím, že máte značně zkreslený pohled na to, co je normální Pravidlo v tomto případě je: "Každý takhle velký kus softwaru je špatně, dokud ho někdo nezdebuguje".

[M. Lox]

Já vím, že v softwaru jsou chyby. Vím, že jsou všude a nedá se s tím nic dělat. Jenom nechápu, proč tu vytahujete nějaký obskurní server, když to nemáte podloženo jinak než tímhle. Podle vaší míry bych se bál používat jakýkoliv FS, protože je tu teoretická možnost toho, že to celé půjde do kytek. Kdybych byl programátor, tak bych za práci pod vámi nedostal zaplaceno ani korunu, protože v mém kódu teoreticky může být chyba.

[MJ]

Nejde o žádný obskurní server. Jde o to, že v kódu Reiser4 jsou chyby v zamykání, které lze snadno odhalit pouhým okem. Vy jste přišel s podivným argumentem, že to chyby nejsou, protože Vám to funguje. Vysvětluji tedy, že pravděpodobně to nefunguje ani Vám, pouze je na Vašem stroji frekvence chyb kvůli malému počtu procesorů natolik nízká, že je nepozorujete.

Kdybyste byl programátor, tak pravděpodobně s tímto přístupem budete produkovat tak mizerný kód, že bych Vám za něj opravdu nezaplatil

[Aleš Kapica]

Ukázku, prosííím. Pokud jde o programování souborových systémů, nejsem na tom tak abych to mohl odhalit pouhým okem, proto bych byl celkem vděčný za ukázku toho kódu a případné vysvětlení toho co je na něm špatně.

[trekker.dk]

#197?

[Aleš Kapica]

Tomu říkám opravdu věcný argument. Kdy byla ta diskuze? Nejsou už náhodou ty věci třeba ošetřené? Ach je tak snadné přihodit link na cizí odpověď, když nevíme kudy kam, že?

[trekker.dk]

Nejsou už náhodou ty věci třeba ošetřené?

A neměli by na to upozornit ti, kteří si přejí začlenění? Není povinnost žádného jaderného vývojáře sledovat cizí projekty, jestli už se autor uráčil opravit chyby - což by tě napadlo, kdybys nebyl kus vola.

Ach je tak snadné přihodit link na cizí odpověď, když nevíme kudy kam, že?

Je tak snadné přihodit link na cizí odpověď, když nechceme psát něco, co již napsáno bylo o kousek vedle.

[Aleš Kapica]

Vulgarity si laskavě nech mezi sobě rovné, ano? Nemám vůči tobě tolik respektu, abych byl ochoten je brát jako přátelské pošťouchnutí.

Ty jsi tím kdo se tady ohání poukazy na chyby, bez toho aniž by takovou chybu skutečně demonstroval na konkrétním kusu kódu. Neurčité blafy, jako že tam jistojistě chyby jsou, když to jedna bába povídala, si nech do hospody.

[trekker.dk]

Vulgarity si laskavě nech mezi sobě rovné, ano?

To jsem přesně udělal. Používám jenom to, co jsi použil ty.

Ty jsi tím kdo se tady ohání poukazy na chyby, bez toho aniž by takovou chybu skutečně demonstroval na konkrétním kusu kódu.

Nemusím pokuazovat na konkrétní kusy kódu, stačí mi poukázat na #257, kde byla chyba v Reiserfs demonstrována dostatečně jasně.

Neurčité blafy, jako že tam jistojistě chyby jsou, když to jedna bába povídala, si nech do hospody.

Jedné bábě bych to asi nevěřil, ale ona to nepovídala jedna bába, že...?

[Ondrej 'SanTiago' Zajicek]

Po velmi kratkem googleni:

http://lwn.net/Articles/99260/

A k tomu o dost pozdeji:

For example, reiser4 used to have (perhaps still does) these cool files that can be both directories and links, and I don't mind that at all, but I _do_ mind the fact that when Al Viro (long long ago) pointed out serious locking issues with them, those seemed to be totally brushed away.

Linus Torvalds, http://kerneltrap.org/node/6922

[anicka]

Ale fuj. Vždyť jste si o pár příspěvků výš sám začal. Co si o sobě vůbec myslíte, když někomu napíšete Ty jsi ale vážně kus.. (prosím dosadit libovolný kus hovězího). a za totéž v bleděmodrém se čílíte? Něco víc než ostatní obyčejní smrtelníci?

Navíc to dělá v situaci, kdy nepřipadat mi to značně nesalónní, napíšu za ten jeho komentář jen "+1" Protože konkrétních argumentů už tady padla fůra. A zrovny Vy byste si pokud vím ten "konkrétní kus kódu" mohl nakonec stejně leda tak vytisknout a pověsit na lustr

[Aleš Kapica]

Mezi volem, bejkem a teletem je dosti velká škála. Na něm bylo aby se ocenil.

Myslím, že ve zdejší diskuzi se objevily i mnohem věcnější příspěvky, bohužel páně Bourkovo z nich nebyl žádný. A jak si můžete povšimnout, zůstala i konverzace na odpovídající úrovni. S jeho křupanstvím nic nenadělám, proto mi nezbylo než se alespoň ohradit.

[trekker.dk]

Myslím, že ve zdejší diskuzi se objevily i mnohem věcnější příspěvky

Mé příspěvky poukazovaly na jiné příspěvky, které informují o chybách Reiser4 a které jsi velice pečlivě ignoroval. To byl jejich účel. Je mi jasné, že se ti nelíbí, protože ignorovat něco, na co jsi výslovně upozorněn, už se nedá vydávat za přehlédnutí...

[Aleš Kapica]

Odkazoval jsi na příspěvky, které pouze sdělovaly, že tam nějaké chyby byly, a týkaly se deadlocku. A že debata o nich někdy proběhla. Nic konkrétního. Vznesl jsem prosbu, zda by MJ nedemonstroval na kousku kódu, když je to pro něj tak očividné, v čem je problém. Bohužel nedočkal jsem se.

Pokud jde o odkazy na konkrétní výhrady, tak linky přihodili jiní a v jiných příspěvcích než na které jsi odkazoval. A pokud jsem si všiml, tak nejčerstvější byly z roku 2006 což je bratru dva roky za námi. Ale alespoň něco.

Takže pokud tady někdo něco vytrvale ignoroval tak jsi to byl především ty. Stejně tak jako jsi ignoroval skutečnost, že informaci o defragmentaci na reiser4 jsem přihodil pouze pro zajímavost a ne proto abych se kasal jaký je to super souborový systém.

Ovšem přiznávám. Je moje chyba, že jsem vůbec na tvé příspěvky reagoval, přestože mě mělo varovat, že tě mám již drahný čas blokovaného. Holt jsem doufal že z tebe vypadne nějaká konkrétní a přínosná informace. Ovšem jako obvykle - marně.

[MJ]

Pro MJ to bylo očividné v onom roce 2006, teď si to samozřejmě nepamatuje a nemá chuť strávit několik hodin přehrabováním se ve starých archivech jenom proto, aby někoho o něčem přesvědčil. Zvlášť když dotyčný nevypadá na to, že by Reiser4 plánoval opravit

Pro mne je stav Reiser4 naprosto jasný: Při posledním review Andrew Morton a Al Viro (jmény si už nejsem úplně jistý, každopádně někdo ze zkušených kernelových hackerů) poukázali na hromadu chyb a požádali maintainery Reiser4, aby až budou chyby opraveny, poslali kód k dalšímu review. To se, pokud vím, nikdy nestalo, takže nemám důvod předpokládat, že chyby někdo opravil.

[trekker.dk]

..., že tě mám již drahný čas blokovaného.

Dobře jsi udělal - když se nám něco nelíbí, není lepší řešení než zavřít oči.

[Aleš Kapica]

Kdybych to takhle dělal, nikdy by nevznikla tahle debata. Tak mi laskavě nepodsouvej svůj přístup.

[trekker.dk]

Můj přístup? Ty blokuješ mě, ale já zavírám oči před něčím, co se mi nelíbí... hm, jo, to zní logicky.

[Aleš Kapica]

Ano, blokuji tě, ovšem neznamená to, že bych tvé příspěvky nečetl. Blokování je pro mne především varování: "Pozor, s těmito lidmi diskuze nikam nevede." Takže v tom není nic osobního. Pokud jde o zavírání očí. Ano, mám ten pocit, protože jinak bys většinu zdejších příspěvků snad ani nemohl napsat. Ještě jednou opakuji - je to jen můj pocit. Takže pokud si jako ona příslovečná potrefená husa na sebe vztáhneš nějakou invektivu, je to jen a čistě tvoje věc.

Ostatně, kdyby sis odpustil svůj příspěvek č.254 tak tahle debata dávno skončila, protože včera vyšel na rootu z mého pohledu docela objektivně psaný článek o reiser4, takže flame na toto téma již hoří jinde.

[M. Lox]

+1

[thingie]

Kam jsme to došli… Ty máš jako nějaký větší rozbor reiserfs4, ze kterého ti plyne, že ten souborový systém je ve všech případech (i na těch víceprocesorových strojích) v pořádku a chová se korektně? Nevěřím tomu. A ani to by nebyl „důkaz“.

„dokud mi neukážete, že je tam chyba, budu to brát tak, že tam není“ -- tohle je u software (a techniky obecně) naprosto zvrácený přístup. Předpokládat, že program je bezchybný? Cože?

[M. Lox]

No, mám ho na několika počítačích, x86 a ppc, obojí 32 i 64 bitů, jedno i víceprocesorové. Na všech jede krásně. Když se porve s dvěma procesory, proč by nemohl se 32? Nebo je snad pro každý procesor navíc potřeba napsat speciální kód? Jestli ano, pak je to stejně chyba spíš Linuxového jádra než R4.
Já nevylučuju že tam ta chyba být může, ale když on napíše: „Kdybyste měl 32-procesorový stroj, možná byste říkal něco jiného,“ tak já chci vědět, co se na 32 procesorovém stroji děje a co bych říkal. On prý, ať si to najdu sám. Takže se neděje nic. Kvůli každému prdu nebudu hodiny prolejzat web.

[trekker.dk]

Když se porve s dvěma procesory, proč by nemohl se 32?

Jestli ono to nebude mít něco společného se změnou pravděpodobnosti deadlocku s měnícím se počtem procesorů...

[M. Lox]

Ano, s určitou pravděpodobností se to položí. Vzhledem k tomu, že jsem neslyšel, že by se to někomu položilo, tuto pravděpodobnost zanedbávám, i když vím, že existuje. Může tam být chyba, ale nikdo ji nenašel. O chybě která se nikdy neprojevila můžu prohlašovat, že neexistuje až do doby, kdy se projeví.

[trekker.dk]

Vzhledem k tomu, že jsem neslyšel, že by se to někomu položilo, tuto pravděpodobnost zanedbávám, i když vím, že existuje.

Tady v této diskuzi to bylo zmíněno. Reiser4 někdo revidoval, řekl, že se může dojít na deadlock, když je více procesorů. Vzhledem k tomu, že revize dělají lidé typu Andrew Morton, tak mně to stačí.

[M. Lox]

Aha. To mi uniklo, že na to přišel někdo při revidování. No nic, já nemám systém s víc než osmi jádry, takže je mi to stejně fuk .

[thingie]

Ono už bavit se o tom, že jsou tam chyby je možná trochu špatně. Tyhle věci je spíš problém dostat do stavu kdy fungují, chyba se většinou chápe spíš jako něco, co se tam omylem dostane, spraví se a je to OK.

Ale jakože jen tak věřit, že se to v takovém prostředí chová správně je docela vtipné. Rozhodně bych chtěl v takovém případě slyšet, že se to chová správně, a ne to předpokládal a zpochybňování tohoto předpokladu považoval za nepodložené žvásty. To je, jak se asi opakuju, zvrhlé.

[M. Lox]

Mně zase přijde zvrhlé říct: „Třicet dva, tečka, a v Reiser4 je chyba.“
Já nepopírám, že tam můžou být chyby, já jenom říkám, ať mi to trochu upřesní. Taky můžu prohlásit, že když mám na ext2 oddílu s velikostí 31,6 TiB soubor o velikosti 165433153 bajtů s názvem YX����g��u�����, tak při fsck zpanikaří kernel, a při dotazu na původ informace vás odkázat na Google (čti: do háje).

[MJ]

Pokud je v kódu možný deadlock, pravděpodobnost jeho projevení obvykle s počtem procesorů roste exponenciálně. Takže pokud by se Vám projevil v průměru za 100 let, tak na 32-procesorovém stroji to může být za chviličku. Nejen může, obvykle bývá.

[M. Lox]

Pokud je v kódu možný deadlock …
… Nejen může, obvykle bývá.

Tohle mám chápat tak, že na třicetidvouprocesorovém stroji jste o žádné chybě neslyšel, jenom připouštíte její možnost? Pak si ovšem rozumíme a já vás tu flambuju zcela zbytečně.

[Kyosuke]

Protože lidé, co si mohou dovolit 32-way CPU server, většinou mají současně dost rozumu, aby na něj Reiser4 nenasadili?

[M. Lox]

Samozřejmě. Ale neprověřený kód se nerovná nefunkčnímu kódu.

[Kyosuke]

Prověřovat kód, ve kterém prokazatelně existují zásadní chyby, nemá snad ani smysl, ne? (Abych parafrázoval Dona Knutha, "Prosím vás o vyzkoušení následujícího kódu, sice mi dokázali, že nemůže fungovat, ale ještě jsem ho netestoval." )

[M. Lox]

Prokazatelně existují zásadní chyby? A jaké? Na LKML se řešilo docela dost chyb, u kterých je už ale všude (skoro) uvedeno resolved/fixed. Pak se tam probírala spousta věcí ohledně stylu, ale nikdo už si nestěžoval na nic konkrétního ani nevznesl kostruktivní kritiku. Pak Hans začal urážet všechny okolo za to, že se zabývají stylem a nevznášejí kostruktivní kritiku nebo něco konkrétního a teď už je pár let ticho po pěšině, protože ho zatkli a zavřeli.

[Jirka P]

Nemám nic proti Reiser4 (přesněji řečeno je mi ... kdesi), ale ?

[M. Lox]

Hmm, tak to je docela síla. Na tohle jsem nikdy nenarazil, škoda, že to odpůrci přijetí víc nezdůrazňují a říkají jenom, že tam jsou nějaké chyby. Díky, je to přesně to, co jsem celou dobu hledal.

[Michal Vyskočil]

Pokud někdo shledává něco vtipného na způsobu zápisu kódu, tak mu to neberu.

To klidně můžeš, ale pokud je ten někdo správce subsystému v jádře, je to to houby platné Navíc ty z pozice člověka, který není programátor a nespravuje hromady cizích zdrojáků, jenom těžko můžeš posuzovat, jak moc důležitá je kvalita kódu pro jeho začlenění a další údržbu. Naštěstí lidé, kteří by se o reiser4 museli starat, jsou ti samí, co rozhodují o jeho začlenění a tak to má být.

[Aleš Kapica]

Nějak tomu nerozumím, soudě dle adresáře http://www.kernel.org/pub/linux/kernel/people/edward/reiser4/ se o reiser4 stará Eduard Šiškin a neřekl bych, že zrovna on je tím kdo rozhoduje o zařazení kódu do hlavní větve jádra.

[anicka]

Pokud někdo shledává něco vtipného na způsobu zápisu kódu, tak mu to neberu. Pro mne je však rozhodující funkčnost. Krásně napsaný, ovšem nefunkční kód si můžete strčit někam.

V každém kódu jsou vždycky nějaké chyby, pokud ale navíc vypadá, jako by jej napsal orangutan, bude je ten orangutan taky muset spravit, protože nikdo jiný se k tomu nebude cítit dost povolán. Což je IMHO jeden ze základních problémů reiseru.

Pokud někdo shledává něco vtipného na způsobu zápisu kódu, tak mu to neberu.

Vtip je v tom, že opravdu nikdo nepíše bez chyb. A v tom, co jsem viděla, nemůže nikdo nikdy všechny chyby najít, ani autor ne.

Krásně napsaný, ovšem nefunkční kód si můžete strčit někam

Něco takového jste někdy viděl? Jednou z pěkných vlastností pěkného kódu je, že se v něm dobře hledají a spravují chyby Proto se taky má psát pěkně, chceme-li, aby to po nás někdy někdo byl ochotný převzít. Věřit, že to můžu zčunit, protože jsem geniální a žádné chyby v tom nejsou, se prostě nevyplácí - vždycky tam jsou.

Ono ohánět se funkčností reiseru je pěkné, ale nevěřím Vám to. Většina chyb, které v programech spravuju, se projevují jen u mizivého množství uživatelů, prostě zatím máte štěstí. Že reiser4 není bez chyb se navíc ví...

[trekker.dk]

Chyba je podle mne něco co způsobuje nefunkčnost.

No a podle vývojářů jádra je to i špatně čitelný kód a spousta dalších věcí. Zdá se ti to hloupé? To je tvoje věc, vzhledem k tomu, že to docela funguje, tak to asi nějaký smysl mít bude.

Jestli se ti to nelíbí, forkni si jádro.

[Aleš Kapica]

Kdyby se mělo jádro forkovat kvůli každé blbosti která je v něm blbě, tak je ho tolik verzí že by se v tom prase vyznalo. Proto používám vanilla a patchuju to co mě zajímá. Uniká mi však logika toho, proč měl Andy Morton ve své větvi -mm ten reiser4 vadný. (jestli je vadný stále nevím, protože se tu jeho větev po špatných zkušenostech ani nepokouším kompilovat) To už by mi přišlo lepší, kdyby ho tam neměl vůbec.

[trekker.dk]

Kdyby se mělo jádro forkovat kvůli každé blbosti která je v něm blbě, tak je ho tolik verzí že by se v tom prase vyznalo.

Na druhou stranu bys prostě měl verzi jádra, ve které je Reiser4 tak, jak ho dodává ten patch. Ale to bys musel něco dělat místo toho, abys brečel, že něco není tak, jak chceš ty.

Uniká mi však logika toho, proč měl Andy Morton ve své větvi -mm ten reiser4 vadný.

V -mm jsou věci, které by mohly být začleněny do jádra. Ta podoba, ve které tam byl kód, byla pravděpodobně proto, aby se možnost začlenění změnila z "určitě ne" na "není to vyloučeno".

[Aleš Kapica]

Já jádro s podporou reiser4 mám, a nabídnul jsem ho i dál pokud by o ně někdo stál. Což si myslím je mnohem víc ku prospěchu než tvé myšlené RTFM.

[anicka]

mi přijdou 4% těch co odmítají tento souborový systém jen proto že jeho tvůrce řešil svou životní situaci zločinem

Sama jsem to sice nezaškrtla, ale vlastně to dává docela dobrý smysl. Podívej:

anketa je zaškrtávací, což znamená, že vybíráš všechno, co Ti přijde aspoň trochu relevantní. To, že Reiser vraždil znamená, že je zavřený a pěkných pár let na systému nic neudělá - a když je zároveň zjevné, že to neudělá ani nikdo jiný, vychází to jako dobrý důvod k nepoužívání související s tou nedodělaností, který bere naději na to, že to bude v dohledné době lepší. Možná je to cynické, ale dá se to zatrhnout ze zcela pragmatických důvodů

Jinak pokud jde o výběr nej filesystému, máme asi tak tři možnosti:

První, strávit dost času benchmarky při svém typickém nasazení a doufat, že je uděláme tak, aby k něčemu byly. Možná to k něčemu vede, ale asi málokdo má na to čas, i kdyby měl schopnost to rozumně interpretovat.

Druhý, vybrat si systém, který se dá spravit, když se rozbije.

Třetí, vybrat si systém podle jména, sympatií k autorům, marketingových žvástů, dle toho co je distribuční default, podle nejhezčího magic number nebo hodem mincí.

Myslím, že ani jeden z těch způsobů není zásadně špatně, ale vždycky je dobré vědět, proč si ten svůj systém kdo vybral... Protože do té třetí kategorie myslím padá většina lidí, co se dnes v diskuzích staví za ZFS, a kdoví, jak to asi bude s Reiserem...

Já se klidně přiznám, že jsem "s nadšením" přeskočila do bodu dva, a to poté, co mě tam z bodu tři vyhnal reiser

[Aleš Kapica]

To že nějakou možnost lze zaškrtnout přeci neznamená, že ji nutně zašktrnout musím. Buďto mě zajímá technická stránka věci a pak si této volby nevšímám, nebo je naopak pro mne prioritní aby vývojáři mého os byli počestní a morálně bezúhonní, pak je na místě.

Ad výběr souborového systému. Prakticky stejné důvody mne vedly k tomu, že jsem zanevřel na ext3. K bodu dva bych jen podotknul, že pro mne ještě hraje roli pravděpodobnost, že se to rozbije. Párkrát jsem řešil rozbitý fs, ovšem prakticky vždy za tím byl problémový hardware.

[MJ]

prioritní aby vývojáři mého os byli počestní a morálně bezúhonní

Spíš aby byli bezúhonní coby maintaineři – tj. aby o nich nebylo známo, že se o svůj kód nestarají (to je bohužel páně Reiserův případ: když pracoval na Reiser4, přestal udržovat Reiser3, ať se starají jiní).

Párkrát jsem řešil rozbitý fs, ovšem prakticky vždy za tím byl problémový hardware.

Právě proto je nanejvýš důležité, aby FS měl perfektní nástroje pro opravování svazků, což například ext2/3 určitě má a Reiser3 určitě nikoliv. Ostatních FS jsem ještě neviděl dost rozbitých na to, abych si učinil nějaký pevný názor

[Aleš Kapica]

Reiserovo chování je zcela logické. Reiserfs považoval za uzavřenou kapitolu, která je volně k dispozici, tak proč by se o něj dál staral. Vymyslet, udržovat a dále rozvíjet jsou naprosto rozdílné věci. Edison taky nevymyslel žárovku v takové formě jakou dnes koupíte v krámě.

[MJ]

Takhle ovšem vývoj jádra nefunguje. Do jádra je přijat buďto kód, který jste ochoten udržovat, nebo takový, který je napsán tak, aby ho po Vás byli ochotni udržovat ostatní.

[anicka]

Párkrát jsem řešil rozbitý fs, ovšem prakticky vždy za tím byl problémový hardware.

To je ale normální, ne? Mně obvykle vychcípl filesystém taky po výpadku proudu, rozbitém napájení disku nebo poté, co ten disk někdo poněkud důrazněji položil na stůl. Nežijeme v ideálním světě, abychom si kdykoliv se filesystém rozbije jinak než z vlastní vůle mohli říct "ale on za to vlastně nemůže" - naopak, právě kvůli tomu, že jsou takové situace běžné, by měl mít rozumné nsátroje, které jej dokážou spravit a s podobnými problémy se do určité míry vyrovnat.

Sám od sebe se mi ext3 nerozbil nikdy, reiser možná jednou (samozřejmě za tím mohl být hw problém, o kterém jsem jen nevěděla). V těch ostatních situacích to je podobné, ale můžete hádat, co se mi dařilo spravovat... jak to vlastně děláte Vy? Vám reiserfsck záhadně funguje nebo používáte nějakou jinou temnou magii? (Nebo se Vám prostě takové věci jen nestávají tak často, protože Vám jednou za měsíc nevypadne proud?)

[Aleš Kapica]

Výpadek proudu, nebo náhodná chyba vzniklá nešetrným zacházením ještě neznamená problémový hardware. V takovém případě bych totiž asi jiný neznal. Moje disky zažily x výpadků proudu (díky postarší elektroinstalaci z počátku padesátých let) a dodnes jedou. Neustálé přenášení jim taky asi nedělá nejlépe. Přesto jsem z nich data dosud neztratil.

Problémový hardware je u mne takový, který začne selhávat bez zjevné příčiny. Zažil jsem to jen párkrát, takže na nějaký statistický vzorek to není. Zpravidla však za tím byly příčiny mnohem rafinovaněji skryté: odcházející IDE port na desce, vadná napájecí větev ze zdroje nebo odpálená elektronika disku.

Asi nejdrsnější "záhadou" na kterou si vzpomínám byl počítač od kamarádky. Měla na disku dualboot. Na tom disku, se skutečně vždy po nějakém čase začal "rozsypávat" souborový systém linux. Windows byly v pohodě. Po druhé reinstalaci mi stříkly nervy, doporučil jsem jí koupit místo původního disku osvědčený seagate a od té doby byl s "rozsypáváním" pokoj.

Podle mě, však za těmi problémy bude matherboard toho počítače, protože když cca po roce změnila způsob přístupu na internet (předtím jela přes bluetooth a mobil) tak jí začaly Windows XP při pokusu o použití síťové karty spolehlivě tuhnout. Linux jel v pohodě. V konečném důsledku to vedlo k tomu, že se tím pádem stal linux jejím primárním OS.

Pokud jde o reiserfsck tak žádnou magii neprovozuji. Vím pouze o jediné komplikaci a to když se poškodí kořenový oddíl. Nejjednoduší většinou bylo ho sjet z nějakého livecd, ale šlo to i v readonly režimu. Pouze jednou dávno v minulosti se mi stalo, že se mi nějak rozdrbal disk a po reiserfsck s volbou --rebuild-tree jsem hledal polovinu souborů v adresáři /lost+found

[krab1k]

Příloha:

• dmesg.log (4151 bytů)

Hmm, tak jsem zkusil Reiser4 na /var/tmp/paludis, pustil kompilaci pár balíčků z svnka KDE4 a přitom si trochu hrál. Nj, už vím, že pouštět echo {a..z}{a..z}{a..z}{a..z}{a..z} je blbost. Každopádně takhle to potom dopadá (viz dmesg v příloze), kromě toho, že se mi sekne kompletně celý počítač. Nejzajímavější je, že se to stalo až docela dlouho po tom, co jsem ten bash odstřelil..

[Aleš Kapica]

Jste si jist že je tohle příčinou vytuhnutí počítače? Mě se tedy alespoň v případě že stroj vytuhne většinou už do logu nic zapsat nestačí.

[krab1k]

Nejsem. Z ničeho nic se mi přestaly reagovat všechny programy v Xkách (a to až po těch mých experimentech), tak jsem se přihlásil v konzoli, pustil dmesg, kde jsem viděl tohle. Chtěl jsem to uložit (dmesg > bug), ale ten příkaz se nedokončil a konzole už nereagovala, přihlásil jsem se do další, tam se mi stalo to samé a ve třetí už se mě to ani nezeptalo na heslo. SysRQ nepomohlo. Naštěstí tlačítko restart mi to nezaseklo, takže jsem to potom vydoloval z /var/log/messages.

[M. Lox]

Jestli máš -mm kernel, tak za to může Andrew Morton a ne Reiser4.
A nedošla ti paměť?

[krab1k]

Patchnul jsem gentoo-sources-2.6.25-r6. Na tu pamět by to i vypadalo, ale v té době už jsem žádný podobný nesmysl (viz výše) puštěný neměl, kompilace dolphinu spadla někde ke konci u ld na SIGSEGV. Takže skutečně nevím, ale moc se mi nechce zkoušet to znova.

[frEon]

WARNING: out of memory? ?

[krab1k]

Toho jsem si samozřejmě taky všimnul. Soudě dle toho otazníku si tím ten systém ale taky nebyl moc jistý. Každopádně já jsem to nijak nezjišťoval (v tu dobu, kdy to ještě šlo, pak už to bylo jedno). Každopádně jsem to sem hodil hlavně kvůli té hlášce z dmesg, ReiserFS, který mám na /, /home ap. se žádnou takovou nepochlubil.