Kam po ReiserFS aneb souborové systémy na Linuxu

Blog na ZDNetu rozebírá situaci okolo ReiserFS 4, který je ohrožen, protože Hans Reiser byl usvědčen z vraždy. Článek především řeší, kam se ohlížet nyní, a shrnuje tak situaci souborových systémů na Linuxu.

29.4.2008 20:07 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[vobrezanej bush]

nebo naopak, kdyz bude sedet, bude mit v base casu dost...

[hafik]

To akoze moze v basa pouzivat pocitac?

[vobrezanej bush]

snad... ovsem bez pripojeni k Netu, tak mohl by commity posilat ven v dopisech :)

[ucho]

spíš v motácích...

[Matěj Cepl]

No, problém bych neviděl jak dostat jeho commity ven, ale jak mu umožnit komunikaci se světem -- nevěřím, že se najde bachař, který by byl ochoten číst linux-kernel list, aby si byl jist, že v něm nejsou propašovávány informace, jak se dostat z vězení .

[Murry]

jj, ten by si přímo početl

[Jirka]

CD zapečené v dortu.

[Dalibor Smolík]

Tajné kódy nového ReiserFS zabudované přímo v instalátoru Windows Vista, SP1

[David Jaša]

Asi budu konzervativní a po usazení přejdu na ext4 (přestože ext3 teď není ani na jedné mašině, o které se starám ).

[xm]

Radši si počkej na Btrfs, to je skutečně moderní filesystem. Ext4 je z mého pohledu šmejd zatíženej děditstvím minulosti, spousta problémů z ext3 v něm přetrvává (a bude přetrvávat), prostě polovičaté řešení, které by bylo možná lepší kdyby vůbec nevzniklo.

A do té doby než se stabilizuje Btrfs mohu osobně doporučit JFS, používám ho už několik let a je to skutečně kvalitní, rychlý a léty prověřený filesystem. Už X let má prakticky všechno co je chystáno do Ext4 a v některých věcech je dokonce podstatně lepší než bude Ext4 (např. dynamicky alokuje inody, u Ext4 bohužel zůstalo dědictví minulosti z Ext3 a inody stále nejsou dynamicky alokovány, v dnešní době je to ostuda!).

[David Jaša]

Troufám si říct, že ext4 tady bude mnohem dřív než brtfs. Co mě úplně nejvíc štvalo na ext3 byl pomalý fsck, který by měl ext4 řešit. JFS používám, ale včera si u mě udělal jeden velký vrub, dovolil si poškodit oba superbloky a fsck.jfs odmítá s ním cokoliv dělat (přestože soubory jsou jako ro dostupné).

[xm]

Já se s nikdy s takovým problémem na JFS nesetkal (mám s ním ty nejlepší zkušenosti, rozhodně lepší než s ext3), ale samozřejmě možné to je. Jinak ext4 tu bude ve stabilním stavu určitě dřív než Btrfs, ale stejně si myslím, že se vyplatí počkat. Přecijen jak říkám ext4 je nepříjemně zatížen dědictvím minulosti (viz třeba to že neumí dynamicky alokovat inody).

[David Jaša]

Já se s nikdy s takovým problémem na JFS nesetkal (mám s ním ty nejlepší zkušenosti, rozhodně lepší než s ext3), ale samozřejmě možné to je.

Já doteď taky ne. Jeho pověst u mě zachránilo to, že data jsou dostupná alespoň r/o, ale budu si teď na nekorektní odpojení dávat mnohem větší pozor. V podobné situaci šel před pár lety na černou listinu reiserfs, který nenávratně poztrácel soubory z okrajů stromu...

Ext3 je u mě nejvíc ztrácí pomalým fsck, což by měl Ext4 spravit.

[m0rph]

Pomalý fsck by měl spravit hlavně metaclustering patch, který se týká jak ext3, tak ext4. Na druhou stranu právě "díky" tomu, že ext3/4 vychází ze starého ext2, má taky fsck asi nejlépe odladěný.

[stativ]

Už X let má prakticky všechno co je chystáno do Ext4 a v některých věcech je dokonce podstatně lepší než bude Ext4 (např. dynamicky alokuje inody, u Ext4 bohužel zůstalo dědictví minulosti z Ext3 a inody stále nejsou dynamicky alokovány, v dnešní době je to ostuda!).

Tady asi někdo nepochopil účel Ext4. To nemá za cíl být supermoderním systém. Cílem je jen „evoluce“ ext3 pro lepší podporu hooodně verlkých zařízení a podobně, včetně zachování kompatibility (už ale ne úplné jako v případě Ext2 a Ext3, to je ale způsobeno právě rozšířením některých struktur). Je to tedy něco jako jako Ext2 -> Ext3 nebo, chcete-li Fat-16 -> Fat-32.

[xm]

To já chápu, a právě proto ext4 nepovažuju za dobrou volbu. Prostě ten systém je už moc zastaralý (to je to dědictví minulosti, o kterém jsem psal). Ale chápu, že to je otázka preferencí a na některých serverech může být ext4 dobrou volbou.

Jinak Btrfs (díky copy-on-write přístupu) umožňuje bezproblémovou online konverzi z ext3 (včetně případného návratu k ext3). Ale samozřejmě než se Btrfs pořádně stabilizuje, tak to ještě tak rok potrvá.

[stativ]

Jo, Brtfs bude krása, ale řekl bych, že ještě pár let ho na produkčních strojích neuvidíme.

[Chocolate Bear]

Zajímavé je, že JFS není např. v openSUSE podporován. A slyšel jsem, že už na něj IBM kašle.

[Petr Tomeš]

JFS (file system) - History

[Chocolate Bear]

Red Meat po česku

[Petr Tomeš]

Chtěl jsem jenom doplnit informaci, kterou jste slyšel.

[xm]

Nešiřte FUD. JFS je nadále od IBM podporován (pokud se objeví chyby, jsou opraveny a změny v kernelu vývojáři sledují). Pouze není nadále aktivně vyvíjen (ono to ani není potřeba, je to solidní stabilní filesystem s dlouholetou historií a přitom s funkcemi které nemá ani ext4).

[pht]

Proc v tom blogu nerozebiraji XFS?

[Dalibor Smolík]

Nevím, možná je to opatrnost způsobená věkem, ale apriori nemám moc důvěru k projektům, které stojí na jednom člověku a nejenom v oblasti IT ...

[Jan Molič]

Jen si říkám, že by bylo škoda, kdyby se nenašli další vývojáři - mám pocit, že projekt stagnoval především proto, že se nevědělo, co s Reiserem bude. Je špatné pohřbít kód jen kvůli tomu, kdo ho vymyslel. Teoreticky by to mohl být jeden z nejlepších filesystémů, který navíc už funguje. Bohužel je taky fakt, že v historii spousta těch nejlepších věcí končí na smetišti. Většinou právě kvůli blbému marketingu. Betamax vs VHS, MS-DOS vs Unix, ...

[m0rph]

Těch faktorů bylo víc - Hans na vývoj projektu sháněl peníze, a zavřeli ho v situaci, kdy se vývoj za poslední rok a půl v podstatě nehnul, protože se vývojáři věnovali předělávání kódu tak, aby vyhovoval požadavkům Chrise Hellwiga & spol. Jinými slovy dělali akorát otravnou rachotu, ke které člověka těžko motivujete jinak než finančně. Tohle je samozřejmě i důsledek sociální neprozíravosti Hanse, který najednou postavil maintainery VFS před svůj systém jako před hotovou věc a pak se divil. Celá tahle snaha navíc vedla z pohledu uživatele akorát k tomu, že se Reiser4 stal daleko méně stabilní (shodou okolností jsem dva dny před zatčením Hanse všechny Reiser4 partitiony odmigroval na Ext3, protože fsck --build-fs jsem potřeboval cca. jednou měsíčně a to už opravdu otravovalo). Na rozdíl od doby, kdy jsem R4 instaloval, už jsem taky byl v pracovním procesu :)

Další problémy, co jsem pozoroval, bylo tragické chování při fsync() (na provoz PostgreSQL zapomeňte), reakce na memory pressure (např. kombinace kopírování hdd->flash_větší_než_ram a stahování ze sítě na hdd), nebo pomalá aktualizace metadat (noatime a nodiratime byla v podstatě nutnost). Fsync problém Hans v nějakém rozhovoru osobně uznal, v mailing listu se to taky chvíli přetřásalo a došlo se akorát k závěru, že řešit to bude "těžké".

Slibovaný repacker je pořád sci-fi.

Extended atributy a ACL taky.

Reiser4 developeři (tj. Ed Šiškin) mají můj obdiv za to, že se o něco snaží, ale šance, že se R4 prosadí, je mizivá.