Vlákno názorů ke zprávičce Dočasné řešení problému ZFS a Linuxu 5.0 od Honzucha - Přibližně před rokem jsem mluvil s člověkem co...

Neviděl bych to tak černě, v roce 2015 vyšla statistika, používání licencí na GitHub a GPL2/3 dohromady měli okolo 22% zatímco MIT 44%.

Jinak nechápu tu slávu mínusu pod mým komentářem, já jsem jen popsal situaci z firemní sféry (záměrně nepíší korporátní, protože mám obdobné zkušenosti i z malých firem).

S mínusy si tu nedělejte hlavu. Dávají se za kacířství, ne za kvalitu myšlenky či sdělení. Lidé jsou veskrze idealisti a neradi čtou o tom, že něco v OSS nefunguje ideálně. Podle mě mají pocit, že neúspěch té či oné věci je daný námi, kteří napíšeme kritiku. To je takový podvědomý dozvuk osvědčeného modelu ve světských i v církevních záležitostech: v první řadě je potřeba opozici umlčet, v druhé řadě už není potřeba nic zlepšovat.

Miroslave, mate pravdu. Jenže ten idealismus právě dělá tento stav. Linux kernel potřebuje stabilní driver ABI. Celá ta teorie, že veškerý driver je třeba tlačit in-tree je prostě zcestna myšlenka, jednak nejsou toto schopni dělat dostatečně rychle, jednak to dělají jen pro mainstream hw. Tento přístup nikdy nebude fungovat pro jejich slovy obskurní hw (mými specializovaný). A i kdyby se podařilo ten driver rychle dostat do in-tree tak ten kernel se tak rychle nedostane do distra. A to si výrobce takového HW nemůže dovolit, takže začínám vidět stav, kdy na systémech je Win Server ačkoliv by tam vůbec nemusel být. A argument máte přece FUSE fakt nekupuju. Jinak já také kde můžu dávám FreeBSD ale ne z licenčního duvodu, ale protože někdy okolo 2006 si mě získalo díky Jails. Teď ještě aby vyladili bhyve a nevidím jediný důvod k používání Linuxu z mé strany. Naštěstí teď dostává i podporu od velkých korporací.

Je opravdu dost dobře možné, že např. na servech bude brzy BSD atraktivnější, než Linux.

Jak už jsem se vám snažil vysvětlit minule, tohle je reálné nanejvýš na nějakých malých systémech pro domácí použití. To je zase ten pohled běžného desktopového uživatele "můj hardware je tam podporovaný, takže je všechno v pořádku". Není. Pokud se dnes bavíme o serverech pro enterprise použití, je řeč minimálně o desítkách procesorů, u větších o stovkách, ve speciálních případech o tisících. Proto máme TCP lockless listener, proto se v hot path všechno, co jen trochu jde, přepisuje na RCU nebo úplně lockless algoritmy, a řeší se i to, jak přerovnat data, aby se minimalizovaly cache misses, proto je takovým hitem XDP (a také proto, že 40Gb/s ethernet je dnes běžná praxe a začíná se prosazovat 100Gb/s).

A pak se pro kontrast podívejte sem, jaké problémy řeší síťový stack OpenBSD. V zápisku ze srpna 2017 se jen tak mimochodem zmíní "Yes, the stack is still mostly single-threaded.". V prosinci 2018 vychází nová verze, která odstraňuje KERNEL_LOCK z podstatné části syscallů pro příjem a odeslání paketů. V Linuxu BKL neexistuje někdy od 2.6.38 vůbec a ve srovnatelných částech síťového stacku byste ho v gitu nenašel vůbec, protože ten začíná až od 2.6.12-rc2 (duben 2015).

Tím nechci říct, že jsou vývojáři BSD systémů neschopní nebo že dělají něco špatně. Ale je jich prostě mnohem méně a někde se to projevit musí. Ta představa, že BSD je takovou o něco méně známou, ale jinak v podstatě srovnatelnou alternativou k Linuxu, je prostě úplně mimo realitu.

@Michal Kubeček:

Rozumím, souhlasím s Vámi, že jsou použití, kde je Linux na míle leaderem. Vámi popisovaná použití se podle mě týkají < 0,01 % případů, možná ještě méně, přesto je v nich Linux nenahraditelný.

Můj pohled je ale trochu jiný. Já zase nejčastěji řeším malé servery do nižších desítek jader, dost často virtualizované. Tam všude se technologie, které zmiňujete, vlastně neuplatní. Pro mě Linux představuje určitou zbytečnou nestabilitu (nemyslím nestabilní běh, ale že co verze, tak se spousta věcí změní) a přínosy z toho jsou jen okrajové.

Monžá jsme narazili na dost často zmiňovanou bolest Linuxu, že cílí na všechno a zároveň na nic. Na desktopu se Linux právě proto neuchytil (resp. toto není věc Linuxu, ale desktopů, ale bolest je to stejná).

Těžko říct, kolik procent uživatelů Linuxu ocení lockless tcp listener vs. FreeBSD AIO. Já jednoznačně víc oceňuji rozvážnější vývoj. FreeBSD pro mě implementuje víc vlastností, které mě zajímají, byť se zpoždením. Méně mě otravuje s výstřelky a většími změnami. Správu na něm provedu levněji a spolehlivěji, než na Linuxu. 40 / 100 GbE zatím neocením, ale také zatím mám historickou zkušenost, že až na to přijde doba, a bude to potřeba, tak to bude mít i FreeBSD zpracované a bez kotrmelců při vývoji.

Proto se tu střetávají dva pohledy, Váš, kterému rozumím, že by Linux bez určitých pravidel a obětí nemohl být tak progresivní. Můj, kdy nechci být zrnko mezi mlýnskými kameny.

Vámi popisovaná použití se podle mě týkají < 0,01 % případů, možná ještě méně,

A jsme zase zpátky u procent počítaných podle počtu desktopů a domácích routříků. To je skoro jako to "na hranici měřitelnosti" v minulé diskusi. Když to nevidím a nemůžu si na to sáhnout, tak to neexistuje. Jenže to je strašně krátkozraký pohled - a právě na těch systémech, které vidět nejsou, Linux už dávno dominuje.

...byste ho v gitu nenašel vůbec, protože ten začíná až od 2.6.12-rc2 (duben 2015).

Oops... tady samozřejmě mělo být "duben 2005". :-)

Já jsem ale mluvil o 40Gb/s a 100Gb/s. 10Gb/s by neměl být problém, ten se mi s dostatečně silným procesorem v rámci experimentování podařilo téměř nasytit i při vypnutí TSO, GSO, GRO a LRO a defaultní MTU 1500. Ale zkuste si přidat do hry connection tracking s trochu rozsáhlejší sadou pravidel a k tomu třeba vxlan, tam už to začne být zajímavé. (To není nějaký hypotetický scénář, to je situace, se kterou se zákazníci řešení založených na openstacku potkávají každou chvíli.)

Ještě k tomu zbytku vašeho komentáře. Celkem vás chápu, já také mám vůči GPL výhrady, které jsou v mnoha ohledech dost podobné vašim. Pokud bych psal něco od nuly, tak bych také použil nějakou volnější licenci. Většinou ale spíš pracuji (ať už v práci nebo ve volném čase) na existujících projektech, takže tam je licence daná.

Všimněte si ale jedné podstatné věci. Píšete, že firmám se licenčně víc líbí BSD systémy a mnohé jim dávají přednost. Jenže to se bavíme o firmách, které ty systémy chtějí používat. Pokud se ale podíváte, jak je to s ochotou podílet se na (upstreamovém) vývoji a přispívat do těch systémů, zjistíte, že tam je situace přesně opačná - a že je to rozdíl spíš v řádech než v násobcích. Samozřejmě si nedělám iluze, že je to výsledek nějakého nezištného altruismu; Intel, AMD, Mellanox, Broadcom a další potřebují co nejlepší podporu svého hardware, Google a Facebook síťový stack, který by zvládal enormní provoz jejich služeb, Microsoft potřebuje, aby linuxové guesty běžely pod HyperV srovnatelně dobře s řešeními od konkurence atd.

Na rozdíl od mnoha jiných nejsem přesvědčen, že je to výhradně zásluha GPL, ale nemůžu nevidět, že svou roli to hraje. Jedna věc je, že BSD systémy vám umožní distribuovat upravený nebo na BSD založený systém, aniž byste dal své změny k dispozici, jiná věc je, že pokud svá vylepšení pošlete do upstreamu, tak je okamžitě může použít vaše konkurence ve svých closed source produktech, aniž byste z toho něco měl. V případě Linuxu to konkurence v closed source nepoužije (nebo by aspoň neměla) a to, čím přispějí oni, budete mít zase k dispozici vy.

Co se týká právníků, to je kapitola sama pro sebe a jejich obavy a zákazy bych nepovažoval za úplně směrodatné. Vím třeba o firmě, která spravuje v linuxovém jádře jeden modul, ale právní oddělení zakázalo jejím zaměstnancům přispívat do jádra kamkoli jinam než do toho modulu - kvůli jakýmsi mlhavým obavám ohledně intelektuálního vlastnictví (ani ten člověk, od kterého jsem to slyšel, to nebyl schopen pořádně vysvětlit, protože mu to nedávalo smysl). A také vím o nejméně jednom schopném vývojáři, pro něhož to byl jeden z hlavních důvodů k odchodu z firmy.

Pokud se ale podíváte, jak je to s ochotou podílet se na (upstreamovém) vývoji a přispívat do těch systémů, zjistíte, že tam je situace přesně opačná - a že je to rozdíl spíš v řádech než v násobcích.

Toto už nerozklíčujeme. Tam má svoji zásluhu GPL, tam má svoji zásluhu to, že Linux už je hodnotná "značka", do které se i ostatním vyplatí investovat. Docela chápu, že se dá obhájit přispívaní do Linuxu, protože ti, kteří schvalují financování přecijen pojem "Linux" slyšeli pravděpodobněji, než ostatní jména OS.

edna věc je, že BSD systémy vám umožní distribuovat upravený nebo na BSD založený systém, aniž byste dal své změny k dispozici, jiná věc je, že pokud svá vylepšení pošlete do upstreamu, tak je okamžitě může použít vaše konkurence ve svých closed source produktech, aniž byste z toho něco měl. V případě Linuxu to konkurence v closed source nepoužije (nebo by aspoň neměla) a to, čím přispějí oni, budete mít zase k dispozici vy.

Já se obávám, že toto v praxi nepředstavuje výhodu / překážku. Pokud chci něco ukradnout, tak to udělám i za cenu toho, že převezmu rámec a přepíšu si to. Pod GPL to nemusí být jiné. Podívám se na to, co jse přispěl, doplním si to a nezveřejním. Situace je ve skutečnosti stejná jako u BSD licence.

Co se týká právníků, to je kapitola sama pro sebe a jejich obavy a zákazy bych nepovažoval za úplně směrodatné. Vím třeba o firmě, která spravuje v linuxovém jádře jeden modul, ale právní oddělení zakázalo jejím zaměstnancům přispívat do jádra kamkoli jinam než do toho modulu

To je čistě věc řízení rizik. Firma ví, že prozkoumat právní problematiku v rozsahu jednoho modulu sice bude něco stát, ale pak ví svá rizika, práva a cenu za právní pomoc. Rozhodnutí je pak o tom, že čistě z opatrnosti není povoleno dělat nic, na co nebyla zpracovaná právní analýza. Zrovna toto mi přijde velmi logické.

Já se obávám, že toto v praxi nepředstavuje výhodu / překážku. Pokud chci něco ukradnout, tak to udělám i za cenu toho, že převezmu rámec a přepíšu si to. Pod GPL to nemusí být jiné. Podívám se na to, co jse přispěl, doplním si to a nezveřejním. Situace je ve skutečnosti stejná jako u BSD licence.

Já přeci jen vidím dost podstatný rozdíl v tom, že v případě BSD licence dotyčný nemusí přepisovat nic a jeho počínání bude zcela legální a v souladu s literou i duchem té licence. U GPL je to jednoznačně proti duchu a i to přepsání může být právně diskutabilní, pokud to od základu znovu nenapíše někdo, kdo neviděl původní verzi.

Já jsem věděl, že s vámi najdu společnou řeč. Jenže toto není problém právníků, ale GPL licence samotné, vždyť i samotní tvůrci ji podle mě nejsou schopni konsistentně interpretovat. Je mě naprosto jasné, že nelze prelicencovat, ale tak to samé přece nelze chtít po ZoL. Co nechápu je ta změna v 5.0 kernelu, byl to úklid kódu a proč tak pozdě. Nejsem jaderný developer, ale vede odtud nějaká cesta? Jako například vlastní implementace zmíněných funkcí?
PS: nejvtipnější na tom je, že FreeBSD zvažuje přechod na ZoL, by se ten projekt mohl přejmenovat ne? ... Trocha ironie na odlehčenou.

Je mě naprosto jasné, že nelze prelicencovat, ale tak to samé přece nelze chtít po ZoL.

Podle mne je ta otázka zcela legitimní. V době, kdy Sun zvolil při zveřejnění licenci CDDL, tu už Linux dávno byl, byl to už dlouho jeden z nejvýznamnějších OS a IMHO i nejvýznamnější open source OS. Pokud tedy Sun zvolil CDDL, dal tím jasně najevo, že o ZFS v Linuxu nestojí. Takže je IMHO zcela logický úhel pohledu, že je věcí Oracle, jestli dál sdílí tehdejší postoj Sunu, tím spíš, že Oracle sám má na Linuxu založenou nezanedbatelnou část svého businessu.

Co nechápu je ta změna v 5.0 kernelu, byl to úklid kódu a proč tak pozdě.

To není pozdě, podobné "úklidové práce" se provádějí prakticky pořád, jen si většiny z nich nikdo nevšimne a není kolem toho takový poprask. Je celkem běžné, že někdo nevědomky odstraní poslední volání nějaké funkce a pokud není static, nemusí si toho nikdo všimnout třeba i pár let.

vede odtud nějaká cesta? Jako například vlastní implementace zmíněných funkcí?

Možnosti jsou různé, jednou je např. ta, o které mluví tato zprávička (která zmiňuje, že se vlastně ani neví, jestli tam je výkonový propad a jak velký).

Spíš bych upozornil na dva detaily, o kterých se moc nemluví. Za prvé, bez ohledu na _GPL, každý, kdo se ve zdrojácích jádra trochu orientuje, ví, že úzus je takový, že symboly začínající dvěma podtržítky jsou typicky interní helpery, a nelze je obecně považovat za externí API a už vůbec ne stabilní API. Za druhé, rozdíl mezi __kernel_fpu_be­gin() a kernel_fpu_be­gin() je jen v zakázání preempce, takže přijmeme-li Gregův výklad EXPORT_SYMBOL_GPL(), nedávalo moc smysl, aby jedna z těch funkcí byla exportovaná bez _GPL a druhá s ním. Přesto nevím o tom, že by se někdo zkusil zeptat Ingo Molnara (který tam to _GPL dal), jestli by souhlasil s opravou na EXPORT_SYMBOL() nebo že by někdo poslal patch, který by to změnil (což se už několikrát stalo v podobných případech v minulosti). Místo toho se nepochopitelně pokusili revertovat ten cleanup, což pochopitelně narazilo na odpor, a spustil se humbuk po fórech, který také ničemu neprospěje.

V každém případě nevidím moc optimisticky dlouhodobé udržování tak komplikovaného filesystému jako ZFS ve formě out-of-tree modulu. Takovéhle - a závažnější - problémy prostě budou průběžně přicházet a ne vždy je půjde triviálně a bez ztrát obejít Takže pokud Oracle nezmění svůj postoj, je IMHO na místě otázka, nakolik je hojně rozšířené přesvědčení, že ZFS je něco, co v Linuxu bezpodmínečně potřebujeme, založeno na technických argumentech a nakolik je spíš odrazem fandovství, stejně jako to kdysi bylo třeba s reiserfs 4. Samozřejmě by také bylo žádoucí, aby si veřejnost konečně uvědomila, že tím, kdo dal použití ZFS v Linuxu do cesty největší překážku, byl Sun, nebyl to ani Sebastian Siewior, ani Ingo Molnar, ani Greg KH, ani vývojáři linuxového VFS.

V době, kdy Sun zvolil při zveřejnění licenci CDDL, tu už Linux dávno byl, byl to už dlouho jeden z nejvýznamnějších OS a IMHO i nejvýznamnější open source OS. Pokud tedy Sun zvolil CDDL, dal tím jasně najevo, že o ZFS v Linuxu nestojí.

Tohle je argument Aničky a Pepíčka na pískovišti, kdo viděl dřív bábovičku. ZFS tu také bylo, a také významné. Já ale pořád nějak nechápu větu "ZFS o Linux nestojí". Do háje, přeci tady nejde o to, jestli Oracle stojí o Linux, ale o to, že uživatelé Linuxu by si ZFS přáli.

Přesto nevím o tom, že by se někdo zkusil zeptat Ingo Molnara (který tam to _GPL dal), jestli by souhlasil s opravou na EXPORT_SYMBOL() nebo že by někdo poslal patch, který by to změnil (což se už několikrát stalo v podobných případech v minulosti). Místo toho se nepochopitelně pokusili revertovat ten cleanup, což pochopitelně narazilo na odpor, a spustil se humbuk po fórech, který také ničemu neprospěje.

Takže Pepíček přesně ví, o co jde. Anička totiž nechce bábovičku, ale potřebuje se natáhnout pro lopatičku. Jenže Pepíček, protože mu Anička do bábovičky kopla, tak jí lopatičku nedá a ještě Aničku udeří.

Pane kolego, tohle je fakt pod úroveň. Mně např. přijde logické v prvním kroku revertovat patch, upozornit na side-effecty, a nechat autorovi "cleanupu", aby se vyjádřil (např. jestli to nechá v původním stavu, nebo vymyslí další patch, co to vrátí zpět). Jestli je důvodem celé kauzy uražené ego, je to smutné.

ZFS tu také bylo, a také významné.

Byl - a jeho zdrojáky nebyly k dispozici, takže linuxoví uživatelé, kteří "by si ho přáli" měli smůlu. Pak byl zveřejněn, ale záměrně a vědomě pod licencí nekompatibilní s linuxovým jádrem, takže se až tak moc nezměnilo. A to je celá podstata problému. Sun sice zveřejnil zdrojáky, ale takovým způsobem, aby ZFS do linuxového jádra začlenit nešel. Když SGI zveřejnili XFS a když IBM zveřejnili JFS, tak takové obstrukce nedělali a oba filesystémy se celkem rychle do jádra dostaly. Opravdu nevidíte ten zásadní rozdíl?

Z nějakého záhadného důvodu ale ty zástupy ukřivděných diskutérů, kteří "by si přáli", neviní ze vzniklé situace Sun (dnes Oracle) a nepožadují nápravu po nich, ale viní linuxové vývojáře a maintainery a nápravu požadují po nich. A z ještě záhadnějšího důvodu jsou přesvědčeni, že jen proto, že se někdo rozhodl přes ten základní a zásadní problém naroubovat ZFS na Linux ve formě out-of-tree modulu, jsou maintaineři povini zapomenout na všechno ostatní a od teď až na věky věků opatrně našlapovat, aby náhodou ten domeček z karet někde nepoškodili. Mohu vás totiž ujistit, že tohle není zdaleka poslední problém se "ZFS on Linux" a že přijdou další a některé z nich budou mnohem hůře řešitelné (jen tak z hlavy vím třeba o plánech umožnit, aby se při exportování souboru omezila viditelnost toho exportu jen na konkrétní moduly).

Mně např. přijde logické v prvním kroku revertovat patch

Já na tom vůbec nic logického nevidím. Commit, který funkci volanou v celém jádře jen z jednoho jediného místa přesune do stejného souboru a deklaruje ji jako static je ve všech ohledech naprosto v pořádku a není sebemenší důvod ho revertovat. Pokud se dodatečně zjistí, že tu funkci volal nějaký out-of-tree modul, je to zcela nezávislý problém, který by se měl také zcela nezávisle řešit; tím spíš pokud se ukáže, že ta funkce nebyla nikdy určena k tomu, aby ji volaly out-of-tree moduly a že i tenhle ji vlastně volal z důvodu, který značně zapáchá.

Pane kolego, tohle je fakt pod úroveň.

To je a jsem moc rád, že si to uvědomujete, jen nerozumím tomu, proč jste ty bláboly o Aničkách, Pepíčcích a pískovištích psal, když si uvědomujete, jak moc to je "pod úroveň". Jestli se tu totiž někdo chová jako Pepíček na pískovišti, tak spíš ten, kdo (v duchu vašeho příměru) kolem sebe plácá ručičkama a vykřikuje "Já chci! Já chci!" a odmítá si nechat vysvětlit, že některé věci jsou holt trochu složitější, než mu to s jeho úrovní informovanosti připadá.

Byl - a jeho zdrojáky nebyly k dispozici, takže linuxoví uživatelé, kteří "by si ho přáli" měli smůlu. Pak byl zveřejněn, ale záměrně a vědomě pod licencí nekompatibilní s linuxovým jádrem, takže se až tak moc nezměnilo.

To je pořád dokola ta písnička o tom hodném a zlém. Na to bych se vykašlal a hledal bych cestu jak umožnit ZFS žít. Jestli tomu dobře rozumím, ZoL nechce nic jiného, než mít přístup k nějaké poměrně elementární funkci, ale na druhé straně není ochota. Bohužel, víc to vypadá, že je to "na oplátku", než že by to bylo neřešitelné.

Pokud se dodatečně zjistí, že tu funkci volal nějaký out-of-tree modul, je to zcela nezávislý problém, který by se měl také zcela nezávisle řešit; tím spíš pokud se ukáže, že ta funkce nebyla nikdy určena k tomu, aby ji volaly out-of-tree moduly a že i tenhle ji vlastně volal z důvodu, který značně zapáchá.

Chápu Vás, ale přijde mi to opravdu zbytečně formalisticky pojaté. ZoL je významný projekt a minimálně to slovo navíc, nebo posečkání, než se vyjasní situace, by si zasloužit mohl, nikoho by to nezabilo.

Jestli se tu totiž někdo chová jako Pepíček na pískovišti, tak spíš ten, kdo (v duchu vašeho příměru) kolem sebe plácá ručičkama a vykřikuje "Já chci! Já chci!" a odmítá si nechat vysvětlit, že některé věci jsou holt trochu složitější, než mu to s jeho úrovní informovanosti připadá.

Ale jo, však já jsem psal, že i Anička má svůj díl viny, šla bezohledně za lopatičkou a rozkopla Pepíčkovi bábovičku.

Popravdě řečeno, mě už to přestává bavit. Zaprvé tyhle žabomyší války nikomu neprospějí.
ZoL není mrtvý a nebude, minimálně v nějaké formě přežije v BSD, i za cenu toho že by se měli vývojáři přesunout k BSD. Filesystém je to robustní, masivně komerčně používaný i v korporátní sféře (narozdíl od BRTFS)
Zadruhé viděl jsem také debatu mezi právníky, a hodně z nich se se shoduje, že jsou nekompatibilní v doslovné liteře zákona, nikoliv v principu (takže by to s největší pravděpodobností soud připustil). Myslím že v OSS je by mělo být důležité šíření zdrojového kódu a to obě licence umožňují beze sporu. Debata vždy bohužel skončí na pro mě militantním postoji GPL.
Take by bylo dobré zmínit, že CDDL ne vlastně ucesana MPL, která až do verze 2.0 byla také nekompatibilní s GPL. Nutné podotknout, že CDDL je kompatibilní s Apache a BSD licencemi. Takže z mé strany je problém s GPL, která je dnes už zbytečně omezující. Ale to je jen můj názor, tak do mě ;)

Větší ... než vzít kód Oracle, protože je možná kompatibilní s duchem licence jsem dnes neviděl a to jsem i kouknul na Twitter Svobodných. Oracle!

(A ano ZFS je skvělý. A ano, GPL není moc povedená.)

ale naprosta vetsina korporatu v produkci btrfs nema

A přesně totéž platí i pro ZFS. :-)

Tak na ten Facebook bych argumentoval CERN který používá ZFS v úložišti dat, dále například IBM Sequoia (supercomputer), jehož paralel storage system Lustre používá ZFS pro cílové ukládání na disk. Co se týče korporací můžeme zmínit OVH, Proxmox, iXsystems, atd... Samozřejmě nesmíme zapomenout na Oracle.

Ještě se vrátím k tomu Facebooku, pokud vím, tak Facebook BRTFS nepoužívá k data storage, ale jako snapshot storage pro containery.

Nechapejte mě špatně, já mám v celku i rád BRTFS, ale ještě má prostě daleko k tomu abych mu věřil a popravdě řečeno to už více věřím NTFS jako data storage, na kterém mame několik desítek TB mssql, nicméně primární data máme v Oracle, Informix a Teradata

Synology ok, tak já ale zas mohu vytáhnout QNAP a iXsystems. Koukněte pokud neznáte ;) ale když se podíváte podrobněji, tak adopce ZFS je přece jenom dále i diky Solaris. Mimochodem v RHEL 7.4 release notes je Btrfs označeno jako deprecated a bude odstraněno v následující major verzi. Což určitě bude mít dopad na pouziti Btrfs v korporátní sféře.

Proč by to mělo mít dopad? Red Hat AFAIK nikdy btrfs jako plně podporovaný filesystém nenabízel, pouze jako technology preview, takže nasazovat btrfs na RHEL v produkčním nasazení by byl holý nerozum. Na SLESu je samozřejmě situace jiná, ale tam se žádný ústup od btrfs neplánuje, přesně naopak.

No když v podstatě nejvýznamnější developer enterprise Linuxu ho ani nehodlá nasadit do produkce, tak to tak trochu dělá dojem, že Btrfs je hobby FS. Takže toto rozhodnutí rozšíření Btrfs tak trochu brání, nemyslíte?

To rozšíření by samozřejmě mohlo být větší, kdyby se Red Hat rozhodl jinak, ale to, že se rozhodli, jak se rozhodli, vůbec neznamená, že je btrfs nějak méněcenný nebo nepoužitelný. U enterprise distribucí je zvykem filosofie "one tool per task" a Red Hat se rozhodl preferovat jiné řešení. Je snad KDE k ničemu jen proto, že RHEL podporuje jen Gnome? Stejně tak není potřeba se obávat, že by se vývojáři btrfs zaměstnaní v Red Hatu museli začít zabývat něčím jiným, protože od roku 2012 tam stejně v podstatě žádní nebyli.

Už se tu ejdnku řešilo jak je Btrfs plnohodnotný a jak je hrozně rozšířený díky Synology. Tak si pojďme nalít čistého vína, samotné Synology Btrfs RAID věří natolik, že ho radši nepoužívá a a běží nad Btrfs Linux RAID. Ten filesystém jednou možná bude použitelný, ale rozhodně ne nebude v příštím desetiletí. Kromě Suse mu chybí podpora velkých hráčů a obecně převažuje nedůvěra. Ani Suse si netroufne ho jako detaily nasadit na datová partitions a mají ho jen na root.

To je pořád dokola ta písnička o tom hodném a zlém.

Hodného a zlého do toho pletete jen vy, já jsem nic takového nepsal. Jen se snažím vysvětlit, že v době zveřejnění ZFS byla licence linuxového jádra dávno daná a dávno už byla situace taková, že i kdyby ji chtěl Linus změnit, stejně by to udělat nemohl, dokonce ani kdyby se k němu připojilo dvacet nejvýznamnějších maintainerů, tak by to nešlo. To není o žádném hodném a zlém, to je reálné zhodnocení situace: Linux svou licenci změnit nemůže, takže veškeré řeči o tom, jak je špatná, jsou úplně zbytečné. Ta licence tu prostě je a taková i zůstane.

Může-li někdo tu nešťastnou situaci opravdu vyřešit, je to Oracle. Proto tvrdím, že by se pozornost těch, kdo ZFS v Linuxu tak moc chtějí, měla zaměřit na něj. To není nic o hodném a zlém, to je o tom, kdo (1) tu situaci způsobil a (2) s ní může něco dělat.

ZoL je významný projekt

Z hlavy a bez velkého přemýšlení vám vyjmenuji nejméně pět přinejmenším stejně "významných" (ve smyslu, že jsou na linuxových systémech hojně používané) out-of-tree modulů: nvidia, vmware, virtualbox, DPDK, veritas, MPTCP, ... A to je jen to, co mi utkvělo v paměti natolik, že se mi to okamžitě vybavilo, ve skutečnosti by ten seznam byl mnohem delší. "ZFS on Linux" vůbec není tak unikátní a výjimečný, aby se z něho maintaineři Linuxu posadili na zadek a dávali pozor, jestli se v něm náhodou něco nerozbije. Pro člověka nahlížejícího optikou "je strašně super, já ho moc chci, nemůžu bez něj fungovat" je to obtížně stravitelné, ale tak to prostě je.

nebo posečkání, než se vyjasní situace

Nevidím důvod. Ještě nemáme ani rc3, 5.0 vyjde nejdříve za pět týdnů a dočasné řešení už navíc je k dispozi (o tom je ostatně tato zprávička). Tak proč honem revertovat commit, který je naprosto v pořádku? Jestli někdo používá out-of-tree moduly v kombinaci s rcX verzemi jádra (což třeba já zrovna na jednom počítači dělám), tak musí počítat s tím, že občas narazí na problémy, kteřé buď bude muset vyřešit sám nebo počkat, až to udělá někdo jiný (já s tím srozuměn jsem).

Tohle je prostě klasická situace typu "you have been warned". Ale ať to varování uděláte sebevýraznější, stejně se dříve či později najde někdo, kdo udělá to, o čem jste ho varovali, že to čas od času přestane fungovat, a pak bude vinit vás, že vy za to můžete.

Ale jo, však já jsem psal, že i Anička má svůj díl viny, šla bezohledně za lopatičkou a rozkopla Pepíčkovi bábovičku.

Nějak se v těch vašich infantilních přirovnáních ztrácím, takže si nejsem jistý, kdo má být Pepíček, kdo Anička, co je bábovička a co lopatka. Jazykem dospělých vývojáři Linuxu od začátku jasně deklarovali, že žádné stabilní API pro moduly jádra negarantují (spíš garantují, že stabilní nebude) a že na out-of-tree moduly brát ohledy nebudou; a teď je najednou (ne poprvé) strašný humbuk jen proto, že se chovají přesně podle toho, na co od začátku jasně a zřetelně upozorňovali.

vývojáři Linuxu od začátku jasně deklarovali, že žádné stabilní API pro moduly jádra negarantují (spíš garantují, že stabilní nebude) a že na out-of-tree moduly brát ohledy nebudou; a teď je najednou (ne poprvé) strašný humbuk jen proto, že se chovají přesně podle toho, na co od začátku jasně a zřetelně upozorňovali.

Už budu reagovat jen na tuto větu, ale i to už se opakuju: já neupírám vývojářům mí takový postoj a držet se ho. Jen si o takovém příliš upjatém postoji myslím své, z mého pohledu to zbytečně hrotí.