Linus szerint inkább ne használj ZFS-t

Fórumok

https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841

Nekem alajában semmi bajom nem volt soha Linus Torvaldssal, de nem igazán kedveltem sose valamiért. De ez alapján a vélemény alapján értem, miért nem szeretik (finoman fogalmazva) oly sokan.

A téma arról szól, hogy valami friss kernel változás töri a ZFS on Linux-ot. Erre Linus reakciója:

  • Röviden: Ne használd.
  • Bővebben: Nem támogatom, mert az Oracle-lel nem akarok ujjat húzni, és nem tiszta a licencelés kérdése.
  • Még bővebben: Nem érdekel ha valaki partizánkodik és kernel modult fejleszt az engedélyem nélkül. Egyébként is megnéztem már, egy szar, miért akarná bárki használni?

Hát, én nem tudom. Az Oracle dolgot megértem, jogos. De az, hogy sok-sok fejlesztővel rendelkező, élő, működő, fejlődő, tömegek által használt szoftver megáll, és ennyire nem érdekli, és semennyire sem konstruktív...

Az ilyen írások miatt érzem olykor azt, hogy hiába a sok milliós fejlesztői és felhasználói bázis, hiába open source jóformán az egész Linux világ, egyetlen idióta kezében van mégis minden, és rajta áll vagy bukik... Ez akkor is gáz, ha történetesen az Ő találmánya/munkája az alap rendszer.

Nem flame-et szeretnék nyitni, nagyon nincs rálátásom az ilyen témákra, csak ez megragadta a figyemem, mert én speciel szeretem és használom a ZFS-t (FreeBSD és Linux alatt egyaránt).

Hozzászólások

Szerkesztve: 2020. 01. 10., p - 17:33

1 byte nem sok, annyit nem tettem még ZFS-re. És még élek. Szóval, nekem nem nagy érvágás, hogy azt mondta, ne használjam :D

Nem flame-et szeretnék nyitni,

Ahhoz képest eléggé sommás véleményt fogalmaztál meg, indulatvezérelve. 

Amúgy pedig nem értem. Mit számít, hogy mit mond neked egy "idióta"?

trey @ gépház

Pedig vannak szuper előnyei. Hogy a sebessége milyen, az nem érdekel. Nekem legfontosabb követelmény a NAS-ban az adatbiztonság volt (amúgy backupom is van), amihez kell a checksumming, a COW alapú snapshot, és a tény, hogy a ZFS egyszerre volume manager és file system. A ZFS már most az, ami a BTRFS majd egyszer lesz, ha nagy lesz.

Ha Linus nem szereti a ZFS-t, az azért baj, mert esetleg aktívan akadályozza a működését/fejlődését. Történtek már olyan commitok a Linuxban, ami a ZOL-nak nehézséget okozott, Linus szerint ő nem direkt akart kiszúrni velük, de direkt nem is támogatja őket, és "hahaha így jártatok" a reakció.

Amúgy meg tök szánalmas, hogy open source projektek így ne férjenek meg egymással. De azt is megértem, hogy az Oracle-nek milyen rossz hírneve van.

Nem vagyok hozzáértő, így csak érdeklődnék: Amennyiben egyetlen másik fájlrendszert sem tört (btrfs-t sem) az új kernel, akkor nem lehetséges, hogy a zfs alapoz egy olyan viselkedésre a kernelben, ami nem volt tervezett?

Nem hiszem, hogy Linusnak ideje lenne a magánélete és a munkája mellett azt tervezgetni, hogy hogyan tegyen keresztbe az Oracle-nek. Viszont neki is van egy sarkos véleménye a rossz fejlesztői hozzáállásról és olyankor ilyesmik születnek.

Mindenesetre tudtommal már rég nem "mindenható" a Linux felett.

Két dolog van.

A Linux kernel belső API-jai folyton változnak. Egy refaktor során Linus forrásában levő minden modul kódját utánahúzzák. A külsősőket nem, az nyilván a külsősök dolga.

Másrészt abban is van eltérés, hogy egyes szimbólumok csak GPL-es modulból elérhetőek.

Tehát a ZFS nem azért törik néha, mert szar a minősége, hanem csak szar helyzetben van.

Ó, azok a csodálatos RC kiadások. Az RC kiadás a Linux kernel esetén nem mindig jelenti azt, hogy már csak az adott merge window-ba került dolgokat javítják. Megszámolni nem tudnám, hogy hány olyan eset volt, mikor valaki utolsó pillanatban küldött be egy nem javításnak szánt patch-et és mégis bekerült a következő kiadásba.

Talán még a 4-es kernel szériánál is volt hasonló, mikor behúztak egy teszteletlen kódot utolsó pillanatban és kikerült a következő verzióval. Majd Linus utána kezdett panaszkodni, hogy azt miért kellett beküldeni tesztelés nélkül és nem győzték kipucolni, hogy a következő verzióban ne legyen benne az adott kód vagy javították.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

> Nem érdekel ha valaki partizánkodik és kernel modult fejleszt az engedélyem nélkül. Egyébként is megnéztem már, egy szar, miért akarná bárki használni?

Ilyet hol írt? Megnéztem a linkedet és azt írta, hogy

"If somebody adds a kernel module like ZFS, they are on their own."

meg azt, hogy

"Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me."
" The benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place?"

Az ő személyes engedélyéről nem volt szó sehol, csak arról, hogy ha valaki új kernelmodult illeszt a kernelhez, az az ő dolga és nem Linusé. Szarnak sem nevezte a ZFS-t, csak "buzzwordnek" (azaz gondolom túlhypeoltnak), meg azt írta, hogy nem teljesít jól a benchmarkokban (hát ha nem tudják beállítani, nem is fog) és nincs mögötte rendes karbantartás (ez meg weaselword, #define rendes karbantartás). Az összes többi a license-ekről szól.

Nem védem Linust, csak ez a félrefordítás így nagyon ki van élezve ellene. Vagy rossz helyen néztem?

Nem félrefordítottam, nekem így jött le ez a szövegezés. Én (valószínű hibásan) beleláttam a "politikailag korrekt" fogalmazást.

Akkor gondoltam, hogy kiírom ezt ide, mikor a végén olvastam ezt a "nincs mögötte valódi karbantartás" dolgot. Ebből nekem úgy tűnik, hamarabb itélkezett és rázta le magáról, minthogy utána nézett volna.

"#define rendes karbantartás"

Ez szerintem inkább csak Linus belső "mércéje". Mivel nagyon sok commit megy át a keze alatt (így, vagy úgy), így azért van némi rálátása arra, hogy mely területek mennyi commitot kapnak 1-1 kiadás során. Ez alapján még akár reális is lehet amit mond.

Másik oldalról viszont a "rendesen karbantartott" (értsd: Meglehetősen sok és gyakori commitokkal piszkált) driverekben is helyenként olyan hibák vannak, amik szintén törnek nem kevés dolgot, de azoknál mint ha kicsit elnézőbb lenne (Intel kínlódása a különböző hibákkal már nem tudom hány kernel verzió óta pl)

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Jogos.. Közben rájöttem, hogy a ZFS kód nem része a kernel fának (szemben a btrfs-el), így azokat nem is küldik be, és így nem is megy át Linus keze alatt

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Intel kínlódása a különböző hibákkal

off: Jaj, ne is mondd, 5.4.8-cal néztem utoljára Intel Pentium N4200-n az i915-öt, még mindig csonttá fagy a gép. :(( Egyelőre azt csináltam, hogy exclude listára tettem a dnf.conf-ban a kernel*-ot, s 5.3.18-at használok, az még nem döglik. Meg persze jeleztem a hibát, de lapítás van, semmi visszajelzés. Nyilván tudnak a dologról. 5.4.10-zel nem néztem, de nincs kedvem leamortizálni a filerendszeren a file-okat, így szerintem megvárom az 5.5-ös sorozatot.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ok, csak ez a commitok száma nem fejez ki semmit. Van olyan microservicenk, amihez az elmúlt két évben érdemi commit nem volt. Talán egy .NET Core verzióváltás volt össz-vissz, azaz 1 db. Funkcionálisan mindent tud, amit kell, piszkálnivaló nincs rajta. Mit kellene oda commitálni?

Szerkesztve: 2020. 01. 10., p - 17:40

Nem szereti, megse tesz keresztbe (direkt) a projektnek (meg ha nem is segiti). Azt, hogy Linus nem akkora hulye pont jol mutatja, hogy a Linux kernel meg mindig az o kezeben van. Mar reg leforkolhattak volna akarhanyan, lehetne Linux kernelbol is legalabb annyi ahany BSD van (vagy Linux disztro), aztan valahogy megse tortent meg ez soha. Mert ugye az vilagos, hogy hiaba tunik ugy, megse egy ember kezeben vagyunk (ez nyilt forrasban szinte lehetetlen is).

Én sem akarok flame-elni, de Linus védelmében annyit, hogy a "megnéztem, szar" vélemény valószínűleg azt takarja, amit én is gyakran tapasztalok. Valaki legyárt egy olyan szoftvert, ami egyébként működik, de láthatóan úgy írták meg, hogy rosszul vagy amikor belenézel a forrásba. Tele van felesleges dolgokkal, áttekinthetelen spagettikód, sokkal több erőforrást használ, mint ami szükséges lenne, globális változók tömkelege, a c konvenciók figyelembevételének teljes mellőzése, ellenőrizetlen pointer típuskényszerek stb. Ilyenkor azt érzem, hogy legjobb lenne újraírni az egészet. A "szerző" azzal védekezik, hogy "de hát működik!".  Az ilyen kódot én sem szivesen építeném be a sajátomba.

Teszem hozzá azonnal, hogy a zfs kódját nem láttam, még csak nem is szeretném minősíteni, csak egy érzést írtam le.

Pedig egyértelműen fogalmaz. Elsődlegesen a szoftver jogi problémák miatt nem támogatja, az egyéni véleménye utána jön. Feltételezem, ha az első indok okafogyott lenne. Nem akadályozná a támogatását.

Szar a posta.

Oda van Shrek.

Revolut blkkolgatja a szamlakat.

Most meg ez is ?

Mi ez mar mindenki helikopter ?

Mindmeghalunk.

http://karikasostor.hu - Az autentikus zajforrás.

Nem ismerem a ZFS-t, de lehet hogy igaza van a véleményével. :) Én elhiszem neki.

Kicsit zavaros nekem a dolog.

A ZFS az SUN találmány, így került az Oracle-höz aki már egyszer perre ment a NetApp-pal de végül elengedték egymás torkát.

Van viszont az OpenZFS project(?) ami próbál csinálni valamit, csak az nem világos, hogy miben különbözik az Oracle-s ZFS-től és mi a tervezett outcome (a "raising awareness"-en kívül), pl. teljesen GPL kompatibilis driver írása from scratch, vagy mi?

Ez az egész "megint eltört a ZFS" több problémára is rávilágít:

* kell legyen egy prod-dal eléggé megegyező teszt rendszered, amin az upgrade-eket kipróbálod élesbe menetel előtt

* a fejlesztőknek figyelniük kell az RC-ket és a changelog-okat.

Nem biztos, hogy jól gondolom, de a levelezésben beidézett szálak közt van, hogy az OpenZFS nem kompatibilis a gpl-lel, mert cddl. Ezért nem haszálhatják a linux belső api-ját közvetlen hívásokra. Ez a tiltás gondolom azért van, mert különben jogi kiskaput nyithatna a kernel gpl alóli kivezetésére. A publikus apin pedig nagyobb munka megcsinálni ugyanazt a funkcionalitást, mit hátulról belehackelni. Szóval nem csak az oracle féle zfs hanem az openZFS is problémás jogilag.

Csakis jogi garancia mellett lenne hajlandó beengedni olyan kódot, hiszen az Oracle már egyszer visszaélt a joggal hasonló helyzetben (ja ez volt az indító link is, csak félrefordított értelemmel)
https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841

És a wrapper kódnak sem látja értelmét, hogy azzal játszák ki a jogi problémákat. (hint: hasonló eset a raspberry pi esetén is ilyen kamu nyílt forráskód van a hardverhez. Valójában zárt a hardver, csak kiadtak egy interfészt, amit a zárt és a nyílt rendszer közé illesztettek)

Plusz volt valami rinya is előtte, valami kapcsán, hogy miért nem engedik be a kódot. Ha jól értem el akarják törni a posix kompatibilitást, mert csak.. és hópihéznek az arra kapott kritikáért, majd utána elmagyarázza nekik Linus, hogy ez a kritika nem sértés, mert tényszerűen rossz a hozzáállásuk, ha azt hiszik majd felrúgják a posix kompatibilitást miattuk.
https://www.realworldtech.com/forum/?threadid=189711&curpostid=189837

De csak felületesen néztem bele egy-egy levélbe... hihetetlen mennyi idejük van

Az OpenZFS az az utolsó CDDL alatt elérhető OracleZFS kód forkja.

Erre az OpenZFS forkra alapoztak a különböző implementációk: ZoF – ZFS on FreeBSD, ZoL – ZFS on Linux, OpenZFS on macOS, OpenZFS on Windows.

Amennyire jók az infóim, az utolsó OpenZFS kódot használó projekt a FreeBSD volt, akik 2019-től átálltak a ZFS on Linux kódbázisára, tehát jelen pillanatban a ZoL - ZFS on Linux minden implementáció alapja, mindenki erre a kódra épít.

A ZoL egy elég aktív projekt, több területen elhúzott az OracleZFS-től, jelentős tempóban fejlesztik, folyamatosan jelennek meg benne újdonságok.

Erre a kódra semilyen ráhatása nincs az Oracle-nek, de több a kódban használt tehnológia szabadalma az ő tulajdonában van, és ez okozza a bizonytalanságokat.

Sajnos már ez sem igaz, mert az Illumos már az OpenZFS-től kapja a ZFS kódot.

2017-ig az OpenZFS az Illumos kódját használta.

2019-ig az OpenZFS tolta vissza a kódokat.

Idéntől meg az Illumos teljesen az OpenZFS-re épít.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Ebben nincs semmi meglepő. Ezek az álláspontjai Linusnak régről származnak. Sose épített be a kernelbe nem teljesen free, nem GPL-kompatibilis kódot. Illetve mindig is alapelve volt, hogy a kernelt szabadon fejlesztik, és nem fognak senki cég kedvéért mindenféle visszafelé kompatibilitásra törekedni, meg 3rd party kódokat kiszolgálni mindenféle kompatilibitási réteggel. Azaz, ha eltörik valami, akkor eltörik. Ezek nem a ZFS ellen megfogalmazott érvek, hanem akármilyen hasonló projektről megkérdeznéd, ugyanezeket mondaná rá. Egész egyszerűen a kernelnek mindig is ezek voltak a fejlesztési filozófiái, ezt előre tudomásul kell venni, ha Linuxra akarsz támaszkodni. Ez ilyen, opensource, free, semmit nem garantál, visszafelé kompatibilitás tekintetében sem. Amíg fut rajta valamit, fut, ha nem, nincs kinél reklamálni. Ha nem szándékolt bug, és egyetértenek vele, kijavíthatják, egyébként nem lehet vele szemben elvárást támasztani.

Ami a többit illeti, én osztom a ZFS-ről általa írtakat is. Lehet nem áll meg, nem is ez a lényeg. Ezek már szubjektív dolgok, mindenki a saját felhasználásából indul ki, így értelmetlen róla vitatkozni. Engem nem érdekel ki mit használ. Tehát nem azt akarom kihozni belőle, hogy örülök neki, hogy eltört az ZFS kernelmodul. Hanem hogy tudomásul kell venni, hogy az ilyen mindig benne van a pakliban, ezért nem is érdemes ilyenekre támaszkodni, vagy csak akkor, ha nagyon muszáj, elkerülhetetlen.

Ez nem Windows, ahol mindenféle API-k mentén 10-20 évig garantált a visszafelé kompatibilitás. Lehet erről vitatkozni, hogy mennyire jó, de én megint csak szubjektív vélemény alapján helyeslem, így nem köti semmi a kernelfejlesztőket, tényleges a technológiai fejlődésre tudnak koncentrálni, tisztán szakmai alapon, és nem kell senkit kiszolgálniuk olyan alapon, hogy ki mit szeretne, kinek a kódja maradjon futtatható, nem megy ilyeneken a politizálás, taktikázás.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Én 10. éve foglalkozom ZFS-sel és nagyon szeretem - a mai napig használom úgy illumoson, mint Linuxon. Nem ez számít ellenben, hanem sokkal inkább az, hogy pl. az OpenZFS project ernyője alatt a FreeBSD implementáció rebase-elte saját kódbázisát a ZoL-ra, tehát itt egy "beleszarok-de-megmondom" típusú, fentről érkező vélemény messze nem csak az adott platform használóit szívatja, hanem kvázi mindenkit, aki bármilyen módon profitál a fejlesztésből. Hogy miért, azt könnyű belátni: a dolog nem egyirányú.

így nem köti semmi a kernelfejlesztőket, tényleges a technológiai fejlődésre tudnak koncentrálni, tisztán szakmai alapon

Akkor esetleg ezek a kernelfejlesztők tisztán szakmai alapon, a technológiai fejlődésre koncentrálva, a jó ötleteket ellopva és továbbfejlesztve cca. 12+ év alatt végre írhattak volna egy jó fájlrendszert! Mert a ZFS funkcionalitását és működését 2006-7 környékétől élesben lehetett megtekinteni a Solarisos felhasználóknál (akkor még voltak).

Na én ezt hiányolom...

Én lebeszéltem magam arról, hogy a fenti állítást megkérdőjelezzem, de akkor felhoznám mégis e ponton a snapshot + send/recv facility-t a checksum + scrub + copies mellé. (Nem, az LVM snapshot nagyon nem ez.) Nyilván volna még mit említeni ezeken felül is.

a 0.0001%-ban! akinek igenye van ilyenre. a tobbi user meg tarolja a single diskjen a homeporeszt, a starwars9-cam.mp4 videonak se kell checksum, az mp3 is kihaloban van, a systemet meg ujrahuzza ha olyan. es magasrol szarik a checksumra, ha elmegy egy bit, azt tuleli.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Linux kernel célközönsége az operációs rendszer építők. (Ha lehet így fogalmazni szabatosan.) A kernel önmagában meglehetősen értéktelen egy home usernek.

Egyébként egy operációs rendszer önmagában még mindig elég értéktelen egy home usernek, nem véltlen, hogy rengeteg felhasználói programot mellékelnek már alapból is mindegyikhez. Még ha néha olyan egyszerűt, mint mondjuk egy notepad. Felhasználók nem a linux kernelt használják, hanem a rajta futó szoftvereket. A kernel csak arra kell, hogy azok futhassanak. Ha nem lenne rá szükség, akkor igazából nem is létezne.

Ugyanígy: egy routeren futó linux esetén is nem a linux az érték a home usernek, hanem maga a router, mint termék.

senki nem mondta hogy a zfs a _home_ usereknek kell (usereket irtam, ebbe benne van a guru szaki is meg a home user is). nemkell nekik, tokre jo nekik az ext4 is. akinek meg zfs kell az hasznaljon rendes zfs rendszert

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

a tobbi user meg tarolja a single diskjen a homeporeszt, a starwars9-cam.mp4 videonak se kell checksum, az mp3 is kihaloban van

Ebben hol vannak a nem home user igények?

akinek meg zfs kell az hasznaljon rendes zfs rendszert

Az a 0.0001%? És mi a rendes ZFS rendszer?

Nade akkor "már miért kéne nekik a tényleges technikai fejlődéssel foglalkozniuk?"

Hiszen a fenti logika szerint a userek 99%-ának megfelel a 15-20 évvel ezelőtti technika is (sőt, még a windows is megfelel nekik), aki bűvészkedni akar, na annak megfelel a 10 évvel ezelőtti, a többiek meg használjanak valami oprendszert... #ohwait, nincs már megfelelő oprendszer, meghalt a Solaris Mátyás, oda az igazság! 

Na ezért szeretnénk, hogy a linux normális legyen.

Hát, a helyes kérdés, hogy vajon 2020-ban van-e már azon a szinten a btrfs funkcionalis-stabilitás szintjén, ahol a zfs tartott mondjuk 10+ évvel ezelőtt... és ezt nem a saját bőrömön (adataimon) szeretném letesztelni.

Hint:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/file-systems-and-storage_considerations-in-adopting-rhel-8#btrfs-has-been-removed_file-systems-and-storage

A Facebooknál is fontos a megbízható tárolás, annak az alapfeltétele az ellenőrző metodikák (pl. CRC) és a replikáció (pl. RAID).
Fontos a sebesség, a könnyű adminisztrálás, a hibatűrés, a hw hibák jelzése, a többszörös meghajtó kezelés.

Ezekben pontosan megegyezik az én elvárásaimmal is.
A workload meg nálunk is pont ugyanez az éles szerverrel kapcsolatban. Ha hibás, akkor azonnal beállítjuk helyette az újat, amire ki van replikálva minden és aztán javítjuk a régit.

A Facebooknál is fontos a megbízható tárolás, annak az alapfeltétele az ellenőrző metodikák (pl. CRC) és a replikáció (pl. RAID).

De kurvára nem a fájlrendszer dolga ez ott sem, ott az megy, mint például nagyobb darabszámú Cassandra esetén is, legolcsóbb hardveren megy mindenből sok és amint egyet köhög a vas, megy a levesbe. Nem dédelgetjük, nem fut fájlrendszer ellenőrzés, nem nézünk CRC-t, nincs RAID, kill and replace, minden más gyógymód drágább ennél.

Ezekben pontosan megegyezik az én elvárásaimmal is.

Ennek igazán örülök, de nem mindig ez a workload kell, ezért teljes mértékben egyetértek azzal, hogy a RHEL-ből kivették, reális problémák miatt, mert amikor van egy fájlszervered vagy kettő adatbázis node-od, akkor hibába jössz azzal, hogy mi van a Facebook-nál millió gépen, ha teljesen más a workload.

Szerintem ezt már ne fokozd, mert egyre rosszabb lesz!

A node minden egyes beolvasott adatnál körbekérdezi a többi hasonló node-ot, "Hé skacok, szerintetek ez jó adat vagy mi a jó adat?".
Kíváncsi lennék a válaszidejére, ha így lenne megoldva! ;-)

Másra való a CRC, a RAID, a Backup és a node töbszörözés. Egyik nem helyettesíti a másikat.
Kérdezz meg egy-két rendszergazdát, ha nekem nem hiszel.

Nem láttál még big datás rendszereket, úgy tűnik :)

Ettől persze még helyi szinten is van logika, hogy érzékeljen sérülést. De, hogy mi a jó adat, azt a magát jónak tartók többsége adja. Ezek nem a helyi fájlrendszerre támaszkodnak. A helyi fájlrendszer csak arra kell, hogy legyen hová tenni az elosztott fájlrendszer node-ra eső részének egy replikáját.
https://dzone.com/articles/how-is-facebook-deploying-big-data

Egyébként úgy látom, hogy nem a tároláshoz, hanem a microservice-ek teljesítmény és izoláció optimalizációjára használják a btrfs-t
https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebook.html

Láttam big datás rendszereket, épp ezért tudom, hogy ott az adat jósága mást jelent, mint helyi szinten.

Helyi szinten azt jelenti, hogy:

  • amit ki akarunk írni adat, tényleg az kerüljön tárolásra,
  • amit beolvasunk adat, az tényleg az az adat legyen, amit a tároló tartalmaz.

Elosztott rendszereknél meg azt jelenti, hogy bejön egyszerre két helyre ugyanarra vonatkozó adat és el kell dönteni, hogy melyiket fogadjuk el. Fizikailag nincs gond egyik adattal sem, csak logikailag.

Ha helyi szinten nem azt tárolod el, ami a jó adat vagy nem azt olvasod vissza, ami a jó adat, akkor nincs semmi értelme a tárolásnak. Erre való a CRC. Ezért van komolyabb gépekben a memóriák esetén is, bár ott nagyon ritkán történik hibázás, de mégis történik. HDD, SSD-nél már sokkal gyakrabban történik, tehát ott még jobban indokolt.
Mivel ott sűrűn előfordul, ezért ott szükség van a hibajavításra is. Azért, hogy egy-két byte-os hiba miatt ne kelljen azonnal kukázni a gépet, ezért a duplikált adatból könnyen helyreállítható a hibás. Erre is való a RAID.

Kifejezetten ellenjavallt a RAID például Cassandra alá és CRC sincs az adataira, mert nincs értelme számolgatni, ha eltérés van, akkor kibukik a következő olvasásnál és vagy javítható vagy meg kell ölni és újrahúzni.

Itt jól el van magyarázva: https://docs.datastax.com/en/dse/6.7/dse-arch/datastax_enterprise/dbInternals/dbIntClientRequestsReadExp.html

Amúgy melyik Big Data rendszert használtad és mekkora telepítés volt a legnagyobb?

Amúgy, az ext4 journal kifejezetten rossz akkor, amikor sok apró írásod van és ezeket mind le kell könyvelje (ugye Big Data), ezért határterhelés elérésekor az egyik út ezeknél a rendszereknél a journal kikapcsolása vagy ext2 használata, aminek a kockázata viszont az, hogy nem várt újrainduláskor fájlrendszer check lesz. A másik tuning opció a barrier kikapcsolása, hogy írjon nyugodtan összevissza, ahogy gyorsabb.  Amúgy bármelyik CoW fájlrendszer fasza, ami támogatott vagy elég bátrak vagyunk hozzá.

A node minden egyes beolvasott adatnál körbekérdezi a többi hasonló node-ot, "Hé skacok, szerintetek ez jó adat vagy mi a jó adat?".

Igen. Van több konzisztencia szint, de nagyjából így megy a dolog, hogy a kérés befut egy node-hoz, ez lesz a koordinátor node, ez rákérdez mindenkinél, akinél elvileg lennie kell adatnak és dönt arról, hogy mi a helyes adat.

Itt jól el van magyarázva: https://docs.datastax.com/en/dse/6.7/dse-arch/datastax_enterprise/dbInternals/dbIntClientRequestsReadExp.html

Van olyan, hogy elég a leggyorsabb helyi node adata, van olyan, hogy a helyi többség adata számít és van olyan, hogy másik adatközpontba is bekérdez, hogy ott mit tudnak a dologról, ez függ attól, hogy milyen konzisztenciát vársz el a kérés kapcsán. A koordinátor node a válaszhoz amúgy nem várja meg minden node adatát, elég a quorum egyezés, így se a lassabb node-ok válaszideje, se a hibás node-ok válasza nem számít, csak a metrikájuk, hogy melyiket kell megölni és kicserélni, mert nem jó válaszokat adnak.

Kíváncsi lennék a válaszidejére, ha így lenne megoldva! ;-)

Próbáld ki, lehet, hogy meglepetést fog okozni, ha ezt eddig nem tudtad.

Nagyon sok esetben megfelelő szintet nyújt a btrfs is, de ha valaki kritikus adatokat akar tárolni, és enterprise szintű fukciókra van szüksége, akkor csak a zfs jöhet szóba, vagy egy enterprise storage.

Röviden a btrfs a zfs egy egyszerű lebutított megfelelője. Én is használom több helyen, már vagy 10 éve, főleg backup adatok tárolására, de snapshotot igénylő szervereknél is, tehát tapasztalom a különbséget a kettő között.

Pont ilyen helyzetekben részesítem én is előnyben a Btrfs-t.

Ezek a gépek 2-4 HDD/SSD-s rendszerek, max raid 1 van bennük, vagy az sem, a tárolt adatok közepesen kritikusak. Ilyen esetben tökéletes a btrfs. Minimális erőforrásigénnyel, megold olyan feladatokat, amelyeket semmi más alapból szállított fájlrendszer nem tud megoldani.

A ZFS az 8+ hdd esetén kezd hasznos lenni, vagy kritikus adatok esetén, mivel alapból sha256 checksumot használ, a btrfs crcjével szemben (az gondolom megvan, hogy a kettő fényévnyire van egymástól minden tekintetben).

A ZFS egy elsősorban tárolók számára optimális fájlrendszer (8+ HDD, 50 TB+ adat), alapszerverek és desktop gépek esetén ritkán jönnek elő az előnyei.

A kiterjedése miatt ide nem pésztelem be (lentebb a link), de itt van pár példa arra, hogy pár parancsból milyen infókat kapsz a zfs-től. Ezek nagyon hasznos információk, és a btrfsből töredékét sem tudod kinyerni, vagy ha ki is tudod, jóval komplikláltabb módokon.

https://home.datanest.ro/f/fda73347a1814747a62f/

Az 5.5-ös kerneltől már a btrfs is támogat komolyabb checksumokat:

In this release Btrfs also adds support for new checksums (per-filesystem, set at mkfs time): xxhash, a fast hash (crc32c successor) with a 64bit digest. Also, two strong cryptographic hashes (both 256bit): sha256 (slower, FIPS), blake2b (faster)

Senki nem fogja ezt megtenni. Azért nem, mert nincs olyan szereplő, akinek ez érdeke lenne. Larry pontleszarja, rajta kívül más maximum újraírni tudná, de ez üzletileg nem kifizetődő (mert akkor meg jön Larry, és kötözködni fog), magának meg senki nem csinálja meg, hiszen használni most is használható, legfeljebb néha vissza kell írni a Linusék által éppen átírt szimbólumlicenc-jelöléseket.

A ZFS funkcionalitása erősen túltesz azon, amit egy jó fáljrendszer tud. Olyan kis mindenes akar lenni, ami miatt a systemd-t például mindenki anyázza :)

Nem a systemd-re akarom kihegyezni a dolgot, de ha olyan dolgok miatt tartod jónak a ZFS-t, ami nem is feltétlenül feladata egy fájlrendszernek, cserébe minden mást szarnak gondolsz, mert nem tudja azt, ami nem is kellene hogy elvárás legyen, akkor rossz következtetést vonsz le (minden szar). 

ami nem is feltétlenül feladata egy fájlrendszernek

Egyetlen ilyen extra funkció van benne, a volume management. Ellentében a systemd-vel, itt az a koncepció, hogy ha akarod, akkor használod, cserébe kapsz előnyöket, de ha nem akarod, akkor használhatod hagyományos módon is, és ez még a solarisos verzióban is teljesen támogatott (még ha nem is javasolt bizonyos performancia előnyök elvesztése miatt). Ha a systemd-ben is minden extra fasság így lenne implementálva, akkor senkinek egy rossz szava nem lenne rá!

minden mást szarnak gondolsz, mert nem tudja azt, ami nem is kellene hogy elvárás legyen

Nem szar: elavult. A hagyományos fájlrendszerek elavultak. Abból a technológiából ezt lehet kihozni. Sok mindenre elmegy (szódával), pont, mint a lovaskocsi (az is működik még falun csomó helyen), de közben feltalálták a robbanómotorokat, úgyhogy aki inkább élvezné az előnyeit, az nem ragaszkodik a lovaskocsihoz. Nem véletlen, hogy a btrfs kitűzte zászlójára a zfs funkcionalitásának jelentős részét.

Szerkesztve: 2020. 01. 11., szo - 08:37

Ez nem egy új történet, már 10 éve is ez volt a sztori, többször csináltak már ilyet, hogy átírtak egy szimbólumot GPL-re, és ez megtört out-of-tree drivereket. Lásd még stable_api_nonsense.txt
Tehát nem is a ZFS-ről szól közvetlenül.

Azt kell látni, hogy a Linus Torvalds által "stabil" kernelként kiadott kernel egy "snapshot" vagy "milestone" releasenek felel meg, amire terméket alapozni csak úgy lehet ha van saját csapatod, akik viszik a karbantartást. Kivétel a különböző LTS kernel verziók (pl. 4.14 egy ilyen, lásd az OpenWRT hírt), de ott sem árt. A most aktívan karbantartott kernel verziók közül a 4.14 és a 4.19 LTS, a 4.14 egészen 2024-ig.

Persze nagyobb disztribúcióknak van saját kernel karbantartó csapatuk, így pl. az Ubuntu még mindig karbantartja a 18.04-hez a 4.15-ös vonalat, és a RedHat-nak is ott vannak a RHEL kernelei. Ezek sokkal nagyobb garanciákat nyújtanak, az RHEL talán még sorozaton belül kernel ABI kompatibilitást is vállal, de már rég néztem.

Ez nem azért van így, mert a Linux fejlesztők direkt ki akarnak szúrni mindenkivel, hanem egyszerűen a Linux kernel fejlesztés egy szinte példa nélkül álló hatalmas szoftverintegrációs projekt, ahol sokezren dolgoznak minden nap egy olyan laza szervezetben, ahol nincs hagyományos felülről érkező direktíva. Az, hogy milyen kódot küldenek be Linusnak az esetek nagy részében reakció a világ változásaira (új hardverek, új felhasználási minták, új kutatási eredmények ... stb.)

Ezek a változások olyan sebességgel történnek, és annyira szerteágazók, hogy valahol kompromisszumot kellett kötni: el kellett dönteni, hogy mik legyenek a prioritások. Ezért szűntek meg a 2.6-os kernelsorozatnál a külön páros/páratlan kiadások, ezért döntöttek úgy, hogy a userspace felé próbálnak stabil ABI-t nyújtani, mindenhol máshol szabad a pálya. 

Itt nincs megállás, nem lehet azt mondani, hogy várjál, most fél - egy évig senki kódját nem vesszük be, mert kitalálunk valami szuperjót. Addigra akkora eltérések lesznek a kódbázisokban, hogy akármelyik változatot emelik be később, a többieknek újra kell írniuk a kódot, amire egyszerűen sose lesz pénz / idő / energia -> már szét is fragmentálódott a projekt. Az, hogy a Linux még mindig itt van, és nem úgy tűnik, hogy bárhová is menne, azt jelenti, hogy valamit nagyon jól csinál Linus, és jól csinál az a sokezer fejlesztő akik ezen dolgoznak nap mint nap.

A Linux előnye, hogy nagyon sokoldalú, és mindenki meg tudja találni benne azt, amire szüksége van. Akinek stabilitás kell, annak ott vannak a disztró kernelek (RHEL, Ubuntu vagy a hivatalos LTS kernelek). De megvan a bemeneti oldal is, hogy az iparban történt új fejlesztések folyamatosan és gyorsan elérhetők rajta keresztül a legtöbb esetben gyártófüggetlen módon.

Én azt gondolom, hogy érdemes figyelni arra, amit Linus mond, és gondolkodni rajta. Olyan szakemberről van szó, aki már kétszer megreformálta a szoftvervilágot: először a Linuxszal, utána a Gittel. Azt is látni kell, hogy ő sem tévedhetetlen, és pont a különleges helyzetéből fakadóan nem biztos, hogy minden, amit gondol, az releváns (vagy éppen követendő) lesz mások számára. Tehát csak azért, mert ő nem használja (mert nincs rá szüksége, vagy más módon megoldja ami neki kell), attól még a ZFS-t nem kell kidobni. :)

A jogi helyzete a ZFS-nek nem egyszerű, de Linus sem jogász. Érdekes módon az Ubuntu pl. bináris formában terjeszt zfs modult...gondolom ott is volt jogászcsapat, akik azt mondták, hogy ez így jó lesz. És a Linux meg másik irányban hordoz jogi kockázatot azzal, hogy annyi különböző embernek a copyrightját tartalmazza, akik mind különböző módon értelmezhetik a GPLv2-t. Ezek a jogi kérdések minden rendszernél felmerülnek, és érdemes szakértőket bevonni az adott konkrét helyzet elemzésébe. Azt sem szabad elfelejteni, hogy a jog (hasonlóan a szoftverhez) egy nagyon is élő dolog, folyamatosan fejlődik, ahogy a világ változásaira próbál reagálni.

Az ilyen írások miatt érzem olykor azt, hogy hiába a sok milliós fejlesztői és felhasználói bázis, hiába open source jóformán az egész Linux világ, egyetlen idióta kezében van mégis minden, és rajta áll vagy bukik... Ez akkor is gáz, ha történetesen az Ő találmánya/munkája az alap rendszer.

Ez Linus, vagy a te véleményed? 

Ez az én véleményem természetesen, miért kérded?

Nekem speciel nem tetszik, hogy elindul sok-sok vita (amiről főképp itt a HUP-on olvasok, mert egyébként nem vagyok érdekelt Linux kernel fejlesztésben), és a vége mindig az így vagy úgy, hogy Linus megmondta, punktum. Egészen biztosan zseniális fickó, de egészen biztosan nem tévedhetetlen. Mégis mindenki (Ő maga is) úgy kezeli. Legalábbis nekem ez jön át az írásokból.

Nyilván fantasztikus mértékű tapasztalata van a szakterületén, ami alapján az esetek túlnyomó többségében jó irányt képvisel, ezt nem vitatom, ha ilyesmi bántana valakit.

Ez ilyen. A kernel az élete munkája, a 3. évtizednyi munkát teszi bele. Így ő szeretné megmondani, hogy mi kerüljön bele, mi legyen a sorsa. Lehet vitatni pár döntését, hogy önkényes, diktatórikus, én sem értek mindegyikkel egyet, de ennyi ideje viszi ezt a hatalmas projektet és az még mindig tart valahova, szóval valamit tutira tud az ürge, és itt nem csak a programozást értem, hanem az egésznek a koncepcióját, meg a szervezőképességét, hogy ilyen hosszú távon is életképes, ennyiféle területen sikeres.

Most képzeld magad bele a helyébe, te tennél bele valamibe ekkora munkát, még ha csak mások segítségével is, aztán jönne valami nímand blogger, meg fórumos McMondó Pistike, ócsárolni életed munkáját, hogy ×4r, nem megyen’ rajta a proprietary szutyka, és te vagy a hibás, meg a te feladatod helyrehozni, hogy neki ingyen meg legyen oldva, azt is tegnapra, mert különben fel fog vonulni tüntetni. Szerintem te is úgy kiosztanád, hogy csak nyekken, és nem a polkorrektséggel meg mások érzéseivel foglalkoznál.

És ezzel nem azt akarom mondani, hogy minden döntése hibátlan, és nem lehet kritizálni, vagy ezt a tudomásra hozni, de az ő szempontjait is meg kell érteni, ha a helyébe képzeled magad, és nem kell meglepődni, ha csípősebb nyilatkozatokat tesz, meg beinti az unalmast.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

A tart valahovát úgy értem, hogy nem fulladt le a projekt, még mindig viszik egy csomóan, van jövője, folyamatosan fejlődik. Nem csak egy vegetáló, vagy elhagyott projekt lett, ami a lecsillapodott hype után elenyészik. Nem konkrét road mapra utaltam, hanem általánosságban írtam.

Azt is külön kiemeltem, hogy sok ember munkája már vagy 20 éve, de ez nem csökkenti Torvalds érdemeit, hogy még mindig ő tartja össze az egész projektet. Ezt nem csinálnák sokan utána, még a programozó zsenik közül sem.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nem tudom a helyébe képzelni magam, így nem tudom megmondani, én hogyan kezelném. Szerintem én egy ekkora (sőt, sokkal kisebb) projektet nem tudnék vinni, és ilyen hosszú távon nem tudna lekötni ugyan az a "harc".

Viszont azt látom, hogy a kernel (hiába van elvileg többeknek beleszólása), csak arra megy, amit Ő egy személyben jónak lát. A hírekből legalábbis ezt lehet kiolvasni. A kritizálást pedig több esetben nem egyszeri fotelprogramozók fogalmazzák meg interneten, hanem olyan, Linus szintjén (tudásban ,tapasztalatban) mozgó emberek, akiknek azért volna alapjuk megjegyzsét tenni, és jó lenne figyelni rájuk. A legtöbb ilyen esetben ezek a hangok sem találnak nyitott fülekre (ahogy olvasom).

Minden sikeres projekt mögé kell egy karizmatikus ember, aki szorosan kézben tartja a döntéseket és határozott elképzelése, célkitűzése van.

Ez nem demokrácia, ahol rengeteg ember a saját pecsenyéjének sütögetése érdekében korrumpálható. Nem lehet több lovat megülni és több urat szolgálni. Ahol ezt teszik, s egyéni érdekek mentén működik a rendszer, az csődhöz vezet. Talán a legközelebb eső példa erre Dell, aki azzal tudta megmenteni az általa alapított céget a bukástól, hogy a pillanatnyi érdektől vezérelt befektetőktől visszavásárolták a döntő többséget jelentő részvény mennyiséget. Nem a diktatúra a legnagyobb probléma, hanem az, hogy mire használja diktátor a hatalmát. Azzal, hogy a cég hosszútávú érdekeit nézi persze maga is jól jár.

Akkor lesz majd nagy baj, ha a karizmatikus vezető kikerül a képből és nem lesz magához hasonló utódja. Akkor a hiénák szétcincálnak mindent és széteshet a projekt az egyének pénzéhségét kiszolgálva.

Úgy tudom, nem először fordult ez már elő a ZFS-sel.

Általánosságban nézve, engem a következők érdekelnének:

  • lehetett tudni jóelőre, hogy jön ez a változás ami eltöri a ZFS-t vagy bármi mást?
  • mi indokolta a változtatást és feltétlen szükség volt-e rá? (pl. része egy nagyobb tervnek, vagy vmi más, "kedvesebb" funkció kedvéért ignorálták a többiekre jelentett hatását?)

Linusnak tényleg meg kellene tanulnia kommunikálni, mert odáig OK, hogy mindenki azt fejleszt a kernelhez amit akar és ő nem tud foglalkozni ezekkel ("If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it, and I can not be bound by other peoples kernel changes".). Az is okés, hogy problémásnak tartja a licenszelést amíg nincs hivatalos Oracle statement ("And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle...").

Az már egy light-os baromság, amikor személyesen Larry E-tól várná a levelet, bár lehet, hogy csak ironizál (nem úgy tűnt eddig, mint akinek sok humora van), de onnantól baromira nem profi, hogy elkezdi minősíteni a ZFS-t (vagy bármi mást): " It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me. [...] The benchmarks I've seen do not make ZFS look all that great."

Konkrétan mi köze hozzá mi az és milyen, ha korábban azt írta, mindenki olyan modult fejleszt amit akar? Ebből kb. az a hiszti jön le, hogy "elbasztuk de nem javítjuk, mert nekem nem tetszik a színe".

 

 

A probléma valódi gyökere ott keresendő, hogy a ZFS kerneldriver része nem kerül bele a vanilla kernelbe. Ekkor ugyanis biztosított lenne supportja, nem törhetne el a fordítás.
A belekerülés feltétele, hogy felvegye a Linux kernel tekintetében a kezdetektől alapelvének számító GPL-v2 szoftverlicenszt (is). Ez pedig nem egyszerű mutatvány így utólag, hiszen a ZFS fejlesztők GPL-től eltérő licensz szellemében ölték bele idejüket és ez a szellemi termék lett később rábiggyesztve a Linux kernelre.

Ergó nem kerül bele a Linux kernelfába és folyamatosan szív a Linux kernel változásai + bizonyos kernel komponensek általi GPL megkövetelése miatt.
Ez valahol arról is szól, hogy akik GPL szellemét elfogadva összeraktak egy ekkora közkincset, azok abban a szellemben tették, hogy aki az önzetlen munkájukra alapozva a kernelbe bármit belefejleszt, az szintén GPL szerint tegye és ezáltal az eddigiekhez hasonlóan bocsássa a továbbfejlesztést közkinccsé.
Bár a ZFS kapcsán jön napjainkban elő a téma, valójában ez nem a ZFS miatt van, hanem enélkül az alapelv nélkül mára szinte biztosan az alakult volna ki, hogy a "közkincs" helyett lenne egy szegényes Linux kernel + cégek saját zárt tákolmányai.

/* Off: miért van teli sleep 1-ekkel a ZFS kernelmodul fordítás? Ennek eredményeképpen fordul brutál lassan, miközben a CPU-t alig terheli. */

> Bár a ZFS kapcsán jön napjainkban elő a téma, valójában ez nem a ZFS miatt van, hanem enélkül az alapelv nélkül mára szinte biztosan az alakult volna ki, hogy a "közkincs" helyett lenne egy szegényes Linux kernel + cégek saját zárt tákolmányai.

Akkor a BSD és Solaris alapú kernelek szegényesek?

> Off: miért van teli sleep 1-ekkel a ZFS kernelmodul fordítás? Ennek eredményeképpen fordul brutál lassan, miközben a CPU-t alig terheli.

Workaround valami race-conditionre?

Az eszközökben igazad van, de annak semmi köze nincs a GPL-hez, vagy a kernelekhez magukhoz, a felhasználóbázishoz viszont annál több; a windows messze több eszközt támogat, mint akárki más, pedig teljesen zárt. Ha a FreeBSD-t, vagy a Solarist használnák annyian, mint a Linuxot, akkor azokra is lenne annyi eszköztámogatás.

A "technológia" egy kissé generikus kifejezés; mit értesz alatta?

"A "technológia" egy kissé generikus kifejezés; mit értesz alatta?"

Nem vagyok naprakesz FreeBSDvel. Olyan featurek mukodnek linux alatt 10 eve, ami FreeBSD vagy Solaris alatt nem leteznek. 

Windows nem tudom, hogy jott ide. Ott is megvan, hogy drivert csak akkor ir ala, ha teljesit valamit a driver vagy a ceg. Volt valami oka, hogy barmikor is kivetelt tett valamivel az MS? 

" Ha a FreeBSD-t, vagy a Solarist használnák annyian, mint a Linuxot, akkor azokra is lenne annyi eszköztámogatás."

Ha nagyanyam(nak).............

Szerintem kevesen vannak, akik csak azert nem hasznalnak FreeBSD-t mert csak xxx device-t tamogat. Nagyok megoldjak fejlesztessel, kicsik meg vesznek olyan HW-t, ami tamogatott.  Ebben nem ertunk egyet, de legyen igazad. Kerdes az, hogy a tobb device tamogatasa milyen aron teljesul. 

> Nem vagyok naprakesz FreeBSDvel. Olyan featurek mukodnek linux alatt 10 eve, ami FreeBSD vagy Solaris alatt nem leteznek.

Ez visszafele is igaz. Például a BSD-kben/OSX-ben lévő kqueue-vel és a SystemV-kben/windowsban lévő IOCP-vel már 20 éve is egyszerűen meg lehetett oldani a C10k problémát, a Linuxban az epoll meg a 2016-ban kijött 4.5-ös kernelig broken volt, lehetett helyette select()-elni. Azaz lehetett volna, de ellentétben a legtöbb rendszerrel (BSD-k, Solaris, windows), Linuxon a descriptor set-ek mérete statikus - 1024-bites - azaz egy processből max. 1024 descriptort tudsz select()-tel figyelni. Lehetett fork() spagettit csinálni. A Linux kernelben van már NFSv4 ACL? Solaris és FreeBSD alatt van. A Xen maximum 4095 magot és 16 TB RAM-ot tud használni, amiből egy VM meg maximum 512 magot és 1 TB-ot; míg a Solarisos Zones-ban ilyen korlátok nincsenek. (És itt egy teljesítményösszehasonlítás is.)
Mindegyik rendszerről el lehet mondani, hogy olyan feature-jei vannak, ami a többinek nincsenek.

> Windows nem tudom, hogy jott ide.

Az eszköztámogatás és a kernel license összekapcsolása okán jött ide, hogy az, hogy egy kernelhez mennyi driver van, annak semmi köze nincs ahhoz, hogy a kernel milyen license alatt van kiadva.

> Ott is megvan, hogy drivert csak akkor ir ala, ha teljesit valamit a driver vagy a ceg. Volt valami oka, hogy barmikor is kivetelt tett valamivel az MS?

Nem tudom, de ez nem fontos, mert az aláírás nem kötelező, anélkül is lehet a drivert telepíteni. A lényeg, hogy a driver - azaz az eszköztámogatás - létezik.

> Ha nagyanyam(nak).............

Ennyi erővel ezt a felfogást az eredeti állításra is lehet applikálni, miszerint a GPL nélkül egy szegényes Linux kernelünk lenne máma. Az is spekuláció.

> Szerintem kevesen vannak, akik csak azert nem hasznalnak FreeBSD-t mert csak xxx device-t tamogat. Nagyok megoldjak fejlesztessel, kicsik meg vesznek olyan HW-t, ami tamogatott. Ebben nem ertunk egyet, de legyen igazad. Kerdes az, hogy a tobb device tamogatasa milyen aron teljesul.

Én a végpontokra értettem. Ha épülne valami nagy felhasználóbázisú termék FreeBSD-re, vagy Solarisra (azaz el lehet adni a tömegeknek), mint történik ez a windows, vagy a Linux (okoseszközök és különféle SBC-k defacto rendszere) esetén, akkor ezek a rendszerek is jobb eszközellátottsággal rendelkeznének. Élő példa rá az OSX, az is BSD kernel, de csak részben nyitott, viszont sokan használják, van is rá driver a legtöbb cucchoz.

A linux kernel egy csomó drivert is tartalmaz. Ettől még lehet harmadik félnek drivert készíteni-e hozzá, de azt a harmadik félnek kell karbantartania. Ahogy az oracle zfs esetén is utóbbiról van szó. Nem a kernelt fogják az oracle szája íze szerint alakítani, hanem az oraclenek kell alkalmazkodnia a kernelhez.

64 bites win alá csak fejlesztői mód aktiválásával telepíthetsz aláíratlan drivert. Az aláírás pedig nem ingyenes. Ha azt akarod, hogy sehol se sírjon a driver miatt akkor whql ezni kell.

> A linux kernel egy csomó drivert is tartalmaz. Ettől még lehet harmadik félnek drivert készíteni-e hozzá, de azt a harmadik félnek kell karbantartania. Ahogy az oracle zfs esetén is utóbbiról van szó. Nem a kernelt fogják az oracle szája íze szerint alakítani, hanem az oraclenek kell alkalmazkodnia a kernelhez.

Ezt én értem, de nem erről volt szó, hanem arról, hogy a license és a támogatott eszközpark mérete nem függ össze.

> 64 bites win alá csak fejlesztői mód aktiválásával telepíthetsz aláíratlan drivert.

Azt pedig be lehet kapcsolni.

> Az aláírás pedig nem ingyenes. Ha azt akarod, hogy sehol se sírjon a driver miatt akkor whql ezni kell.

Lehet, de itt a driver létezése volt a kérdés, nem az, hogy az ms kínjában már mindent kitalál, hogy a biztonságot növelje, vajmi kevés sikerrel. Az eszközgyártók egyébként nyilván alá fogják irattatni a driverüket. Ennek ellenére több driver van windows alá, mint Linux alá. (És amúgy tudtommal ez csak a vista óta van így, márpedig előtte ugyanúgy a windowsnak volt több támogatott eszköze.)

"Mindegyik rendszerről el lehet mondani, hogy olyan feature-jei vannak, ami a többinek nincsenek."

Nem ertettel meg, en a mennyisegekrol beszelek. AmigaOS-ben is van fantasztikus megoldas, de ettol meg nem fogom tudni hasznalni.

Solaris es FreeBSD is jo termek, es biztos vagyok benne, hogy ezek hasznalata a leheto legjobb valasztas szamtalan helynek.

"Ha épülne valami nagy felhasználóbázisú termék FreeBSD-re, vagy Solarisra (azaz el lehet adni a tömegeknek)"

Lehet, hogy igy lenne, de nem nincsen ilyen termek, es nincsen lathataron.

"Nem tudom, de ez nem fontos, mert az aláírás nem kötelező, anélkül is lehet a drivert telepíteni. A lényeg, hogy a driver - azaz az eszköztámogatás - létezik."

Nem ertem akkor mi a ZFS-sel a problema, utolso kernellel mukodni fog. Produktiv kornyezetben sokkal rosszabb usigned driverrel szenvedni, mint hogy regebbi kernelt hasznalsz linuxhoz.

> Nem ertettel meg, en a mennyisegekrol beszelek. AmigaOS-ben is van fantasztikus megoldas, de ettol meg nem fogom tudni hasznalni.

> Solaris es FreeBSD is jo termek, es biztos vagyok benne, hogy ezek hasznalata a leheto legjobb valasztas szamtalan helynek.

Én azt hiszem, te nem értettél meg: én arra próbálom felhívni a figyelmet, hogy a kernel képességei nem függenek a license-től.

Amúgy milyen mennyiség? Márhogy melyik kernelnek van több feature-je? Hát erre jó volna valami hiteles összehasonlítást látni, hogy melyik kernel mit tud, hogy mire alapozod, hogy a Linux kernel tud többet. A Wikipedia idevágó cikke használhatatlan, mert a Linux/OSX/windows triumvirátust leszámítva a többi rendszer sorait kvázi kérdőjelekkel töltötték fel.

Az lehet, hogy neked ez felel meg, mert azt tudja, ami neked kell, de ez nem azt jelenti, hogy a többiek kevesebbet tudnak, hanem azt, hogy azt nem tudják ami neked kéne.

> Lehet, hogy igy lenne, de nem nincsen ilyen termek, es nincsen lathataron.

Feltételes mód, továbbá ld. első bekezdés.

> Nem ertem akkor mi a ZFS-sel a problema, utolso kernellel mukodni fog. Produktiv kornyezetben sokkal rosszabb usigned driverrel szenvedni, mint hogy regebbi kernelt hasznalsz linuxhoz.

Semmi baj nincs a ZFS-sel; ld. első bekezdés.

Hát, azért pont a ZFS-nél én nem egy magáncég saját kódját látom, ami csak neki jó elsősorban, hanem kettő teljesen nyílt forrású fejlesztés/projekt aktuális egyesítést.

Értem, hogy GPLv2, meg CDDL, meg a többi, de ha ezek végül is mind ugyan azt a célt szolgálják különböző módokon, és Linus annyira jó szerverző, akkor miért nem foglalkoznak egy kicsit azzal, hogy ezeket "kompatibilissé" tegyék, vagy valamilyen (jogi) formában kölcsönösen elfogadják egymást valamilyen feltétel rendszer mentén?

Biztosan nem csak a ZFS-nek válna előnyére (és nem csak a Linux kernelnek), ha kicsit elmozdulnának a licencelés miatti ennyire szigorú elkülönüléstől.

De itt van ez a ZFS dolog. A Linux kernelben hasonló ugyan van (BTRFS), de ahogy én látom, messze nem kap annyi feljesztést, ami ráférne (és messze nem kap annyit, mint a ZFS), de mivel GPLv2, ezért azt támogatják, babusgatják. A másikat meg megölik egy licencelést érintő változtatással, amit - mivel nem kifejezetten műszaki változás ahogy én értem - lehet, hogy jó ideig (vagy örökre) megoldhatatlan marad. Na, ha ez így lesz, ez fogja azt eredményezni, hogy akik a ZFS mögött állnak, azok maradnak a legutolsó, számukra működő Linux kernelen, és máris kész a szakadás... Egy idióta jogi helyzet miatt, aminek semmi köze semmilyen informatikai műszaki kérdéshez...

Nyilván a megoldást nem tudom, és nem is gondolom, hogy valaha meg tudnám találni. De vannak nálam sokkal okosabb emberek, és nagyon csodálkozom, hogy mégsem tűnik úgy, hogy ezt meg akanák oldani.

és nagyon csodálkozom, hogy mégsem tűnik úgy, hogy ezt meg akanák oldani.

 

Ahogy látom, a ZFS most kezd igazán feltűnni a linuxos horizonton (OK, nyilván nem volt eddig sem ismeretlen, de az Ubuntu is most jobban beállt mögé, itt is sok topic nyílt az utóbbi időben, stb.). Remélem kialakul egy olyan fajta nyomás, ami közelebb hozza egymáshoz a feleket.

Főleg úgy, hogy nem tudom az Oracle-nek mi közvetlen haszna származik a copyright-ból (https://tsdrapi.uspto.gov/ts/cd/casestatus/sn85901629/content). Amúgy sem ők találták ki, hanem a Sun, szóval én a helyükben bedobnám a ZFS-t a közösbe (GPLv2 v. akármi) és csinálnék vmi foundation-t vagy legalább egy architektúra team-et ami koordinálná a fejlesztését aztán hagy szóljon. De biztos megvan az oka, hogy nem tesznek így (akárcsak annak, hogy nem én vagyok az Oracle CTO-ja :) ).

Ez a jogi helyzettől független közeledés elképzelés teljes nonszensz. 

Az oracle a jogi helyzet alapján perelné be és tenné tönkre / tenné zárttá és lopná el a linux kernelt. Nem hiányzik nekik egy google-oracle per megismétlés.

Linus Torvalds  nagyjából olyan személyiség, mint Steve Jobs, csak nem az önkényes design a fétise, hanem az önkényes code quality.

„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”

... végül is a világon az összes létező szoftver közül a Linux kernel a legstabilabb dolog... úgyhogy ha Linus valamire azt mondja, hogy szar, akkor az szar.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Például. De ott van a macOS is. A többit ne bántsuk, fogjuk rájuk, hogy nem általános használatra vannak.

 

FreeBSD-re építettem egy backup szervert pár éve. Két lemez volt benne, ráizzítottam egy zfs-t raid1-es vdev-el és menjen. Egy darabig minden szép és jó volt. Aztán elkezdtek reallokálni a lemezek.

Még ment így egy darabig, sacc 1-2 hónap. Aztán szépen lementettem róla mindent. Mindkét lemez hibás volt, jócskán, a gép reszponzív maradt végig.

Sosem értettem minek 20 millió féle fájlrendszer. Egy kellene, ami jó és kész.

robyboy

Pontosan.

Részletesebben: nincs csak jó vagy csak rossz fájlrendszer. Mindegyiknek van előnye ill. hátránya. Ezért majdnem tökmindegy, hogy melyiket használod, mert nyersz is, vesztesz is. Ha csak egy fájlrendszer lenne, legalább nincs ebből probléma. Ja, és lehetne rá HW-ket optimalizálni. Ki lehetne a szart is hajtani a rendszerekből.

robyboy

" egy szar, miért akarná bárki használni?"

A systemd-ről mi a véleménye?

2014-es véleménye:

"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

bcachefs-t senki se hasznalja?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....