Problém ZoL (ZFS on Linux) na Linuxu 5.0

Vývojáři ZoL (ZFS on Linux), tj. implementace OpenZFS (Wikipedie) na Linuxu, řeší problém s Linuxem 5.0 (#8259). V Linuxu byla provedena refaktorizace kódu FPU. ZoL požadované funkce jsou nově dostupné pouze pod licencí GPL a tak je v ZoL s licencí CDDL nelze použít.

11.1.2019 19:22 | Ladislav Hagara | Komunita

Komentáře

[Kandidat viet]

... a tak sme sa tesili na ZoL :D a opat pre sproste licencie je to v <>

[Peter Golis]

Politika je základný nástroj politruka.

[deda.jabko]

A nebylo by lepsi opravit ZFS tak, aby se FPU vyhnul dostatecne velkym obloukem? Prece jen mame rok 2018 2019.

[Jindřich Makovička]

SSE/AVX/AESNI instrukce už jsou out? Něco mi uniklo?

[Peter Golis]

Skôr je otázka prečo sa spoliehajú v dnešnej dobe na nejaké optimalizácie FPU ASM pre x86 (32bit). To naozaj odmietajú aby to fungovalo na iných platformách, napríklad ARM, PowerPC 64 a podobne?

[Michal Kubeček]

Je celkem běžná praxe, že sice existuje generický kód v C, ale pro nejběžnější architektury je pro nejkritičtější věci k dispozici i verze optimalizovaná "na krev" přímo v assembleru.

Z upstreamové diskuse jsem měl pocit, že je to vlastně spíš z nouze ctnost, protože správné řešení by bylo použít implementaci z crypto subsystému, ale to by taky narazilo na EXPORT_SYMBOL_GPL().

[Peter Golis]

Nemyslím si že v dnešnej dobe je 387 (FPU ASM) najbežnejšia architektúra. Oni to vyvíjajú v korporáte že si nevšimli príchod nového milénia?

[Michal Kubeček]

Jako obvykle se vám podařilo zcela minout obsah příspěvku, na který reagujete.

[Peter Golis]

Reagoval som presne na prvú vetu toho príspevku:
Je celkem běžná praxe, že sice existuje generický kód v C, ale pro nejběžnější architektury je pro...
Ak tá veta nemala súvis s problémom opisujúcim nedostupnosť asm/i387.h, tak to nebol môj problém. Ale kľudne pokračuj.

Pripomenulo mi to problém z pred niekoľkých rokov keď sa FF nedal buildnúť mimo x86/64 a ARM kvôli absencii generického kódu optimalizácie JS. Vtedy som prestal používať Linux ako desktop na architektúre Power. Keby to bola bežná prax mať taký generický kód, tak ani jeden tento problém neexistuje.

[Michal Kubeček]

Architekturou se v tomto případě pochopitelně rozumí x86_64 (nebo třeba právě vámi zmíněný ARM), ne "387".

[deda.jabko]

To mi prave nejde do hlavy, pokud si dobre vybavuju, uz v prvnich manualech k AMD64 bylo, ze FPU (x87) je tam z duvodu podpory legacy aplikaci a SSEx je preferovany zpusob pro praci s plovouci carkou a vektory.

Pred bezmala deseti lety jsem resil u MyJIT, jestli ma cenu (je nutne) podporovat generovani kodu i pro FPU, ale uz tehdy se x86 procesory bez SSE daly najit jen v embedded svete. Takze mi prijde divne, ze kod pro FPU nekde preziva dodnes, nota bene v projektu, ktery ma ambice byt nasazovan do produkce a na dlouhe roky.

[Michal Kubeček]

To byste se musel podívat do zdrojáků toho modulu, k čemu přesně to používají a proč. Podle té diskuse, na kterou jsem odkazoval, je docela dobře možné, že je to jen ugly hack, jak se vyhnout použití crypto API. Báječný svět non-GPL modulů je holt ještě veselejší než báječný svět GPL out-of-tree modulů.

[Peter Golis]

Matematický koprocesor 387 je FPU pre 32bit architektúru x86. Môj prvý pracovný desktop krátko po revolúcii to nemal, mal len CPU 386 bez koprocesora. Za tú dobu som nezabudol čo to je.

A používanie tak starobylého kódu považujem v dnešnej dobe za riziko, s dosahom o ktorom hovorí momentálna nemožnosť kompilácie ZoL. A nie je to jediný dôkaz že generický kód v C pre takéto príležitosti chýba. Proste, zaspali 20 rokov. A doplatili na to.

[Michal Kubeček]

Ten fallback nefunguje tak, že by se generická implementace automaticky použila, když selže build specifické. Kdyby to tak fungovalo, byla by to dost nepříjemná past, protože by při jakékoli chybě způsobující chybu překladu build stejně úspěšně doběhl.

Abych pravdu řekl, vůbec mne nezajímá, proč a jestli vůbec FPU potřebují. "ZFS on Linux" používat nehodlám. Jestli to někdo používá nebo dokonce na tom staví komerční produkty, je to jeho problém. Koneckonců, dodnes se najdou i nadšenci, kteří v praxi používají reiser4…

[Peter Golis]

Keby ten fallback bol, tak ho rovno použijú a daný bug by bol tým pádom vyriešený. A to aj keby sa malo jednať o patch na build proces.

[Michal Kubeček]

Keby ten fallback bol, tak ho rovno použijú a daný bug by bol tým pádom vyriešený.

To není vůbec jisté. Máme teprve -rc1, za pár hodin bude (pravděpodobně) -rc2, takže 5.0 final téměř jistě nevyjde dřív než za pět týdnů. To je dost dlouhá doba na to, aby se vývojáři ZoL nejdřív pokusili přesvědčit vývojáře jádra, aby jim umožnili používat dál to, co mají teď (případně s malou obměnou), a teprve když to nepůjde, začali hledat jiné řešení. Koneckonců, z diskuse je zřejmé, že z jejich pohledu je to jen drobné opomenutí. Navíc i když generická implementace existuje, může být v některých případech oproti optimalizované dost neefektivní (jinak by to ani nemělo smysl dělat tak složitě).

[Peter Golis]

Tak na to mali snáď už dosť času od piateho mája roku 2015, čo je ku dnešku len tisíc tristo päťdesiat dní, alebo čosi vyše tri a pol roka. Ak je vynútené používanie niečoho, čo patrilo do minulého tisícročia, aj s takmer štvorročnou ignoráciou zmien v jadre len drobným pozabudnutím sa, tak by ma zaujímalo v ktorej korporácii to majú ako súčasť kultúry.

[Michal Kubeček]

To je bohužel u out of tree modulů naprosto běžný přístup - věci se prostě řeší až v okamžiku, kdy selže build nebo něco přestane fungovat (způsobem, který nelze ignorovat). Čest výjimkám. Teď se třeba od 5.0-rc1 začal při použití SUBDIRS vypisovat warning, že je to deprecated (a bylo už odpradávna) a že po 5.3 to bude odstraněno; schválně můžete sledovat, kolik out of tree modulů používajících SUBDIRS to opraví teď (místo SUBDIRS stačí použít M) a kolik jich to začne překvapeně řešit teprve až jim build opravdu selže.

To je IMHO také jeden z důvodů, proč vývojáři a zejména maintaineři jádra často out of tree moduly a jejich problémy ostentativně ignorují. Spousta out of tree modulů by totiž mohla a měla dávno být v mainline a víceméně jediný důvod, proč nejsou, je ten, že mimo strom mohou jejich autoři provozovat bohémský přístup, který by jim v mainline nikdo netrpěl. Nikdo je nenutí dodržovat coding style, nikdo jim nemluví do toho, jak reagovat na chyby, jaká rozhraní používat a jaká ne, … prostě klídek a pohodička.

Ale nic není zadarmo, takže za tu svobodu se holt platí tím, že je občas potřeba něco přepsat (za což by byl ve stromě zodpovědný ten, kdo to rozhraní změnil). Někteří to špatně nesou a pak za pomoci kliky věrných uživatelů prskají po fórech, jak jsou ti vývojáři zlí a házejí jim klacky pod nohy.

[Michal Kubeček]

Jiný názorný příklad zmiňuje tenhle commit message. Ten modul sleduje současně jiffies a gettimeofday() a ty dva časy navzájem koriguje podle jakýchsi empirických pravidel, což je podle všeho workaround na to, že kdysi dávno nebyl v jádře zdroj monotonního času s dostatečným rozlišením. Ten je sice k dispozici už od 2.6.17 (2006), ale vmmon (který už se starším jádrem dost možná ani nefunguje) to dodnes dělá postaru a zbytečně složitě a neefektivně.

[Peter Golis]

Pobavilo.

Klasický korporátny prístup: Nechytaj sa toho, pokiaľ to ako tak funguje.

[lertimir]

Greg se už vyjádřil ve čtvrtek. Nakloněn "přesvědčování" tedy není.

[Michal Kubeček]

Není - a kdo je aspoň trochu v obraze, těžko to od něj mohl čekat. Ale Greg nemá žádné právo veta a pár příkladů, kdy se nějaký symbol z podobného důvodu zpřístupnil, by se našlo. Tím ale nechci říct, že to tak určitě bude i v tomhle konkrétním případě (můj tip je že spíš ne), jen že z pohledu vývojářů ZoL to "stálo za pokus".

[Tom K]

Naopak. FPU registry jsou používané pro MMX/SSE/AVX/.... operace. Jsou dost velké a jejich ukládání při každém volání do kernelu by bylo drahé (obvykle je kernelový kód nepoužívá). Proto se ukládají jen na vyžádání pro specifický kód. Je lépe si dotyčný kód přečíst než jen tak plácat (stačí vyhledat fpu_begin a toho kódu zase tolik není). Zmenšuje to šanci být později za blbce (nic osobního).

[deda.jabko]

FPU registry jsou používané pro MMX/SSE/AVX/....

To neni pravda. FPU tj. ST(x) registry jsou sdilene jen s MMX. SSE, AVX, a spol. maji vlastni, oddelenou, sadu registru.

[Michal Kubeček]

jejich ukládání při každém volání do kernelu by bylo drahé (obvykle je kernelový kód nepoužívá). Proto se ukládají jen na vyžádání pro specifický kód.

Bejvávalo… Hint: LazyFPU.

[Tom K]

Hezké. Děkuju.

[deda.jabko]

SSE/AVX/AESNI instrukce už jsou out? Něco mi uniklo?

Nerozumim otazce. Moc do toho kodu nevidim, ale nechapu, proc by ZFS melo potrebovat nejak pracovat s FPU. Jsou dve moznosti (i) vypocty s plovouci carkou pres x87, (ii) MMX. Ani jednou z toho mi neprijde dobry napad, kdyz je vsude (tam kde miri ZFS) minimalne SSE2.

[LinuxTARDIS]

Myslím, že na diskuzi na Phoronixu jsem se dočetl, že to je víceméně jediné podporované řešení. Pokud někdo chce něco počítat v plovoucí čárce, má k tomu použít usermode helper. Pak je FPU řešené jako u standardních aplikací. To byl nejspíš jeden z důvodů, proč byly ty fynkce označené jako zastaralé.

[luky]

Koukam na patch a pozadovane funkce nejsou pro moduly dostupne vubec (protoze je zadny vanilla modul nepouziva). Informace o licenci mi prijde irelevantni.

[.]

This commit removes an exported function pair that is currently used by out of tree modules, while the replacement pair (kernel_fpu_begin/end) is EXPORT_SYMBOL_GPL.

[luky]

Zpravicka rika "ZoL požadované funkce jsou nově dostupné pouze pod GPL". Pritom ty pozadovane funkce nejsou uz dostupne vubec - proto to selhalo uz pri kompilaci - protoze z hlavicek zmizelo "extern void _kernel_fpu_begin(void);"

Pokud by se zmenila jen licence symbolu, k selhani by doslo az pri linkovani modulu do kernelu (pri insmod).

Podobnou funkcionalitu (rozdil je pouze ve vypnuti preempce) zprostredkovava i GPL symbol, ktery chteji lide ze ZoL prelicencovat na GPL, aby ho mohli pouzit misto "zmizelych" funkci. Jenze tento symbol byl uz od zacatku exportovany pouze pres EXPORT_SYMBOL_GPL.

Vysvetleni ve zpravicce je vadne, protoze vpodstate rika ze nekdo zmenil EXPORT_SYMBOL na EXPORT_SYMBOL_GPL, coz se nestalo.

[Petr Ježek]

Potvrzuji.

[lertimir]

Greg K-H:

My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?

[ewew]

Tiež si myslím, že použiťvať niečo mimo jadra s nejakou divnou licenciou je cesta do pekla.

[Petr Tomášek]

To je taky blbost vyvíjet cokoliv „jaderného“ pro Linux pod jinou licencí než GPL...

[Max]

Nezačali od nuly, je to port ZFS na Linux.
A tento jejich port je podporován různými komerčními řešeními.
Zdar Max

[Petr Tomášek]

Nezačali od nuly, je to port ZFS na Linux.

No a? Měli to přelicencovat na GPL a bylo by po ptákách (dokonce by pak ZFS mohlo být plnohodnotnou součástí jádra). To, že to neudělali, je ten zásadní problém, a ne, že z jádra vyhodili jakési pofiderní nepoužívané API!

A tento jejich port je podporován různými komerčními řešeními.

A proto nemůže být pod GPL? To je teda hovadina^n! (Linux není podporován různými komerčními řešeními???)

[Petr Ježek]

Myslím, že by bylo dobré se vrátit ke všem diskusích ohledně licenocání ZFS. pak jsou jisté příspěvky zcela zbytečné. "Převést na GPL" je v tomto případě asi tak snadné jako stanovit A u neutrin.

[Max]

Nemohli přelicencovat na GPL, protože ten původní kód je CDDL a vlastní ho Oracle. Oracle by musel ZFS přelicencovat a pak by to bylo ok. Jenomže Oracle má Solaris, kde je ZFS nejnativnější a staví na tom storage. Jeho tedy nic netlačí k přelicencování, ba naopak, pro něj je výhodnější ZFS neuvolňovat a držet se ho co nejvíce. I když je zde samozřejmě FreeBSD, kde je to licenčně ok. K uvolnění pro linux je pak jen krůček.

Pokud jde o podporu komerčních řešení, chtěl jsem tím říci, že ten kód je už tak stable a tak používaný, že se ho nebojí ani komerční subjekty.
Zdar Max

[Bedňa]

A tento jejich port je podporován různými komerčními řešeními.

Ale to je ich problém keď si to chcú uzavrieť.

V skratke nasrať na softvér ktorý nemá slobodnú licenciu aj keď si to autori softvéru myslia.

[Peter Golis]

Ktorými, prosím? Rád si rozšírim obzor.

[Max]

Myslím, že Proxmox oficiálně dává podporu na ZoL. Což je asi dáno i tím, že ho Debian taktéž oficiálně začal podporovat a ostatní distribuce taktéž.
Pokud se pletu, tak mně někdo opravte.
Zdar Max

[Peter Golis]

Tešil som sa že sa dozviem niečo o podpore ZFS v Oracle Linuxe, alebo o stave TRIM ktorý fungoval keď spoločnosť Nexenta mala vlastnú implementáciu ZFS.

Ten Proxmox je ako aktívny pri vývoji alebo riešení problémov s ZoL, či len predáva Debian s pridanou hodnotou vnútrofiremnej Wikipédie?

[Max]

TRIM pro ZFS v Solarisu je, nevím, jak dlouho, ale dlouho. Ve FreeBSD je od verze 9.2 a v ZoL je ve formě revize.
Nexenta je komerční produkt založený na Solarisu, který bývá ve všem dost vepředu. TRIM by tam mít měli, ale třeba oss illumos ho údajně ještě nemá. Taktéž má Nexenta dávno podporu pro NFS4.1 a HA řešení.
Celkově mi přijde, že vývoj OSS Solaris like systémů zaostává. Podobně mi to přijde i s FreeBSD, kde je oproti Linuxu také hodně pomalý vývoj.
Zdar Max

[Peter Golis]

Ja stav TRIM v ZFS poznám, a viem že TRIM v ZoL je plánovaný až v gen.9. Illumos ten TRIM naozaj nemá, stačí si vytvoriť virtuálku s thin provisioning a overiť si či sa disk zmenší po odmazaní dát.

Mňa zaujímal stav komerčnej podpory pre ZFS ktorá reálne rieši potreby trhu, nie preklepy v zákazníkovej konfigurácii.

[jdsulin2]

Vytvaret jaderny modul, ktery je tak spjaty s jadrem jako je filesystem, je mimo strom, bez licence GPL docela silenost. Chapu, ze zrovna u ZFS to kvuli CDDL nejde, ale zmeny muzou prijit obecne jakekoliv. Sice teda nechapu, k cemu potrebuje kod pro filesystem vypocty s plovouci carkou, ale predpokladam, ze to spise bude nejaka instrukce pro praci s celymi cisly ze sad MMX apod.