Jaderné noviny - 8. 10. 2008 (diskuse)

[M. Lox]

…souborové systémy, stejně jako ovladače zařízení, jsou dostatečně oddělené od zbytku jádra, takže brzké začlenění nemůže příliš škodit. Určitý druh precedentu byl také nastaven brzkým "začleněním" ext4, i když to byla evoluce existujícího souborového systému ext3, zatímco Btrfs je zcela nový. Andrew Morton Chrise povzbudil, aby Btrfs dostal do linux-next okamžitě a začlenil ho do 2.6.29…

Vzpomínáte na Reiser4?

[CIJOML]

na vrahem vytvoreny fs sere pes a doufam, ze reiser dela v krimu defku

[Nikola Ciprich]

no tys tu chybel :-/

[stybla]

na vrahem vytvoreny fs sere pes ...

eh?

[Nikola Ciprich]

taky jsem si na to hned vzpomnel, ale tam byl problem v tom, ze reiser4 je o dost vice intruzivni, meni snad i veci ve VFS, atd. a Hans to svym pristupem taky zrovna nezlepsoval. ac me to velice mrzi, tak ted uz reiseru4 moc velke sance nedavam :(

[M. Lox]

Kdepak, nemění nic mimo svůj kód, rozhodně nic společného pro jiné části jádra a tak důležitého, jako je VFS. Jediným důvodem skutečně byl Hansův přístup, což však mnoho vývojářů vehementně popírá a schovává se za technické důvody. I kdyby tam však nějaké byly, tak tímhle prohlášením jejich váhu stejně popřeli.

[trekker.dk]

Kdepak, nemění nic mimo svůj kód, rozhodně nic společného pro jiné části jádra a tak důležitého, jako je VFS.

Právě naopak VFS obchází a duplikuje funkce.

Jediným důvodem skutečně byl Hansův přístup, což však mnoho vývojářů vehementně popírá a schovává se za technické důvody.

Pohádka o zlých vývojářích. Reiser4 byl revidován, Hans dostal seznam věcí, které nevyhovují a je potřeba je změnit. Pak začal vývojářům nadávat a nezměnil nic. Čiže: technické důvody tu byly první.

[M. Lox]

Právě naopak VFS obchází a duplikuje funkce.

1. Ale nemění nic mimo svůj kód, takže když ho při kompilaci vypneš, dostaneš jádro identické s neopatchovaným. Neexistuje důvod pro nezařazení takového kódu, jak dokazuje i Andrewova citace výše.
2. Jediný mně známý případ tohoto je cryptocompress, jehož obdobu, i když zatím méně propracovanou a silně nestabilní, obsahuje btrfs taky.

Pohádka o zlých vývojářích. Reiser4 byl revidován, Hans dostal seznam věcí, které nevyhovují a je potřeba je změnit. Pak začal vývojářům nadávat a nezměnil nic. Čiže: technické důvody tu byly první.

Právě o ten seznam tu jde. Vývojářům btrfs totiž IMHO nikdo nic takového nedal, protože jim řekli, že bugy budou odstraněny až v jádře, což je (mimo jiné) Linusova politika, se kterou já souhlasím. Hansovi bylo naproti tomu oznámeno, že R4 bude začleněn teprve až v něm žádné chyby nebudou.
Dále vezmi v úvahu, že R4 byl ve chvíli kdy ho Hans navrhl k začlenění již docela stabilní, zatímco btrfs je stále téměř nepoužitelný, ale přesto bude začleněn.

[trekker.dk]

Ale nemění nic mimo svůj kód...

To je ale fuk. Když se pokusíš začlenit kód, který obsahuje duplicitní funkce, tak s největší pravděpodobností pohoříš bez ohledu na to, jestli to je souborový systém, ovladač nebo změna správy paměti.

Vývojářům btrfs totiž IMHO nikdo nic takového nedal, protože jim řekli, že bugy budou odstraněny až v jádře, což je (mimo jiné) Linusova politika, se kterou já souhlasím. Hansovi bylo naproti tomu oznámeno, že R4 bude začleněn teprve až v něm žádné chyby nebudou.

Ano, protože v té době se to tak dělalo se vším. Politika začlenit opravdu brzo a chyby opravit až v jádře je stará pár měsíců.

Navíc zrovna u R4 nebylo vůbec jisté, jestli chyby budou opraveny. Vzhledem k tomu, že Hans prohlásil, že to tak je správně a ostatní jsou kreténi, dá se očekávat, že by s tím nehnul. A po zkušenostech s R3, na který se úplně vykašlal a jeho údržbu museli převzít jiní, se nedivím, že vývojáři nechtěli riskovat to samé znovu.

Dále vezmi v úvahu, že R4 byl ve chvíli kdy ho Hans navrhl k začlenění již docela stabilní, zatímco btrfs je stále téměř nepoužitelný, ale přesto bude začleněn.

To jo, ale do linux-next. O začlenění do hlavní řady v žádném případě není rozhodnuto.

[M. Lox]

Tak já to shrnu:

• Oba jsou do značné míry revoluční, obsahují novinky
• Oba obsahují jednu (a jedinou) fci, která by měla být jinde (komprese)
• Ani jeden z nich nemění cizí kód
• R4 je mnohem stabilnější
• Oba jsou aktivně vyvíjeny
• Bývalý vývojář jednoho z nich byl idiot

Když odečteme oblasti, ve kterých jsou oba stejné a ty, které jsou již záležitost minulosti, tak tu zbyde to, že je R4 stablinější, ale přesto není začleněn.

[trekker.dk]

To shrnutí je hezké, ale

Oba obsahují jednu (a jedinou) fci, která by měla být jinde

Tohle není tak úplně pravda - respektive rozhodně nebyla, když H. Reiser navrhoval začlenění.

Oba jsou aktivně vyvíjeny

Z čehož jeden PODSTATNĚ rychleji, že?

Když odečteme oblasti, ve kterých jsou oba stejné a ty, které jsou již záležitost minulosti, tak tu zbyde to, že je R4 stablinější, ale přesto není začleněn.

To by se o to někdo musel snažit. Reiser skončil u toho, že o vývojářích jádra prohlásil to, co o nich prohlásil a o další začlenění se nesnažil. Teď, když ho zavřeli, se o začlenění snaží někdo jiný, nicméně vzhledem k tomu, že btrfs může být za Reiser4 dostatečná náhrada, pochybuju o tom, že svůj záměr dotáhne do konce. Podporu ze strany ostatních vývojářů nicméně má.

[M. Lox]

Tohle není tak úplně pravda - respektive rozhodně nebyla, když H. Reiser navrhoval začlenění.

Poprvé možná, ale on to navrhoval vícekrát. Minimálně první dva pokusy se navíc obešly bez invektiv.

Z čehož jeden PODSTATNĚ rychleji, že?

Druhý je zase podstatně dál už teď

[alblaho]

To neprošlo ze dvou důvodů. Za prvé, vývojáři se nesmířili s některými vlastnostmi R4 jako třeba možnost otevřít si soubor jako adresář (není to košer, totiž ehm, POSIX). No a za druhé, Hans byl špatný komunikátor.

Btrfs má rozhraní standardní a jeho vývojáři nejsou sociopati. Takže bych v tom neviděl problém, ten kód je opravdu izolovaný, nic jiného neovlivní.

[M. Lox]

Zrovna tuhle vlastnost vyhodili, a, jak jsem už napsal, R4 taky nic mimo svůj kód nemění.

[stybla]

Vzpomínáte na Reiser4?

Vzpominam si hlavne na to, ze "communication failed" viz co napsali ostatni.

[al-Quaknaa]

Já ho třeba používám a nevím o jiném FS, na kterém funguje transparentní komprese tak snadno jako na reiser4 (mimo to, že je už tak dost rychlý). Na btrfs čekám hlavně proto, že reiser3 už začíná stárnout (nelíbí se mi jeho fragmentace při využití nad 80% a nemá žádné pokročilé funkce - snapshoty, komprese, šifrování), vypadá dobře a bude nejspíš lepší než ext*. I když žádný expert nejsem, že...

[alex]

Používám Reiser 4 nějakou dobu, i když nikoli v produkčním prostředí. Jsem s ním spokojen, rychlost při práci s malými soubory nemá konkurenci, stabilita výborná, přestože Reiser 4 není dokončen.

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

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

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

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