Indiaas bedrijf bouwt native zfs-kernelmodule voor Linux

Het zfs-bestandssysteem, dat door het voormalige Sun werd ontwikkeld, krijgt mogelijk toch een native implementatie voor Linux. De Indiaase firma Knowledge Quest Infotech zou zfs in de vorm van een kernelmodule hebben gebouwd.

Hoewel het zettabyte file system in onder andere OpenSolaris, FreeBSD en NetBSD wordt toegepast, heeft het 128bit-bestandssysteem nooit een complete overstap naar Linux gemaakt. Oorzaak is dat de cddl-licentie van het voormalige Sun niet compatibel is met de gpl-licentie, die op de broncode van de Linux-kernel berust. Via een omweg, een implementatie via het Fuse-project, kan zfs weliswaar in userspace legaal worden gedraaid, maar deze methode heeft prestatieverlies tot gevolg.

Phoronix meldt nu dat het in India gevestigde bedrijf Knowledge Quest Infotech een native zfs-implementatie heeft ontwikkeld. Deze kan als een optionele kernelmodule in de Linux-kernel worden gecompileerd. Volgens de bijbehorende cddl-licentie wil de firma de broncode van zijn zfs-implementatie op 15 september vrijgeven. Momenteel loopt er een gesloten bètatraject. Het bedrijf zegt niet bang te zijn voor moeilijkheden met Oracle, de databasereus die vorig jaar Sun overnam en liet weten dat het geenszins van plan is om zfs van een gpl-licentie te voorzien.

Volgens Phoronix is de zfs-versie van KQ Infotech gebaseerd op het vrij recente Zfs Pool 18, maar beschikt het niet over features als de-duplication die wel in de laatste vrij verkrijgbare versies van OpenSolaris waren terug te vinden. De kernelmodule werkt alleen samen met 64bit-Linux-kernels. Naast het vrijgeven van de broncode zullen er rpm-installatiebestanden verschijnen voor Fedora 12 en Red Hat Enterprise Linux 6 Beta 2. Daarnaast wordt het mogelijk om zfs aan de kernel van Ubuntu 10.04 LTS toe te voegen.

Hoewel zfs nu beschikbaar komt als kernelmodule voor Linux, is het onduidelijk of KQ Infotech in de toekomst geld voor zijn creatie wil zien. Ook is het de vraag of de voordelen van zfs, zoals schaalbaarheid en het beveiligingsniveau, nog opwegen tegen de moeite die moet worden genomen voor het implementeren ervan. Dit hangt samen met de komst van btrfs, een vergelijkbaar bestandssysteem dat wel aan de gpl-licentie voldoet en een groeiende populariteit kent.

Reacties (62)

[Verwijderd]

Bied ZFS voor de normale sterveling zoals ik extra voordelen t.o.v Ext4 ?

@Sfynx
Dat met dat Deduplicatie zie ik niet helemaal in: wat is daar anders aan dan een symolic link aanmaken behalve dat het automatisch gebeurt ?

[Reactie gewijzigd door Verwijderd op 29 juli 2024 09:59]

[Sfynx]

1 storage pool verspreid over meerdere schijven, waarbij stille corruptie automatisch hersteld wordt als deze pool redundant is (mirror, raid-Z, raid-Z2), ingebouwde snapshots en clones die ook gekopieerd kunnen worden naar een andere machine, ingebouwde compressie op blokniveau, best wat voordelen En als je OpenSolaris gebruikt: deduplicatie, hoe geweldig is dat, maak een kopie van gegevens en er komt geen gebruikte ruimte bij

Naar mijn weten is het op dit moment het enige echt dataveilige bestandssysteem dat productieklaar is. Voorzover je het alleen een bestandssysteem kan noemen, aangezien RAID en LVM mogelijkheden erin zijn geïntegreerd (wat weer tot leuke dingen leidt zoals alleen gebruikte ruimte hoeven synchroniseren na het wisselen van een schijf).

[Reactie gewijzigd door Sfynx op 29 juli 2024 09:59]

[rvl1980]

deduplicatie, houdt dat dan een beetje hetzelfde in als het maken van een hard-link van bestanden onder EXTx ? Of zitten er nog andere voordelen aan?

[nhbergboer]

Deduplicatie is het huidige marketingwoord voor Content-Addressable Storage ( http://en.wikipedia.org/wiki/Content_addressable_storage ). Je kunt dat op blokniveau of op fileniveau doen, maar het principe is vergelijkbaar:

Stel dat je (even voor het gemak) dit op fileniveau doet, dan gebeurt (conceptueel) het volgende: Ik save bestand file000.txt. Het systeem berekent vervolgens een hash (bv. MD5, of SHA1, of langer) van de _inhoud_ van het bestand, en houdt op de schijf een mapping bij van hash naar inhoud. In de directory files wordt vervolgens alleen "file000.txt = die_hash" opgeslagen.

Als dus iemand anders dat exact hetzelfde bestand opslaat, dan wordt weliswaar in de betreffende directory file wel "nieuwe_filename.txt = die_hash" opgeslagen, maar in de hash-content map wordt niets nieuws opgeslagen.


Het cruciale punt in deze is dat je wilt dat twee verschillende bestanden niet dezelfde hash krijgen toebedeeld. Helaas kun je die kans niet uitsluiten (P = 0), maar je kunt die kans wel astronomisch klein maken (in het beste geval circa P = 2^(-(n/2)), als je hash goed is, en n bits heeft). Waarom n/2, en geen n? Wel: zie http://en.wikipedia.org/wiki/Birthday_paradox .


Je kunt datzelfde natuurlijk ook op blokniveau doen; ik weet niet precies wat ZFS doet.


Edit: Het verschil met een hardlink is dat, zodra je bij een hardlink een van beide bestanden verandert, de ander meeverandert. Als je in een CAS de nieuwe_filename.txt verandert, wordt in de directory file "nieuwe_filename.txt = nieuwe_hash" opgeslagen, en in het content map "nieuwe_hash = nieuwe_inhoud". De bestanden blijven dus twee onafhankelijke bestanden, hoewel ze opslagruimte kunnen delen (dat is dan transparant voor de gebruiker).

[Reactie gewijzigd door nhbergboer op 29 juli 2024 09:59]

[Munters]

Natuurlijk moeten de bestanden ook nog bit-voor-bit vergeleken worden wanneer er een identieke hash gevonden wordt. Juist omdat de kans niet 0 is dat dit niet voorkomt. (Anders zouden we een perfecte compressie uitgevonden hebben!).
Daarom wordt er altijd een "hash + volgnr" gebruikt als id.

Het toevoegen van een tweede hash voegt overigens niet zoveel toe. Dat heeft hetzelfde effect als het aantal bits van de eerste hash te verdubbelen. Het wordt wel gebruikt, want het kost vrijwel niets als je ze tegelijk berekend.

Ik vraag me trouwens nog steeds af of dit soort systemen echt slim is.
Bij het opslaan van een nieuw bestand is het duidelijk, maar stel ik sla bestand 1 op, en vervolgens (een ander) bestand 2.
Nu open ik bestand 2 en wijzig daar een paar bytes, waardoor bestand 2 ineens gelijk wordt aan bestand 1.
Ik neem aan dat er dan geen deduplicatie plaats vind?
(tenzij dedup op blokniveau plaatsvindt?)

Of draaien er nachtelijke processen die alle gewijzigde files nalopen en deze alsnog deduppen?

[Verwijderd]

Bij een NetApp SAN welke dedup op block niveau doet wordt dit inderdaad gescheduled (Standaard 's avonds).
Dit process voert de dedup uit m.a.w. er wordt niet direct dedupliceerd.

Indien een dedupliceerd bestand gewijzigd wordt zal dit op een andere lokatie opgeslagen worden. Er zal dus nooit een situatie ontstaan waarbij er 2 bestanden gewijzigd worden.

[TonnyTonny]

Dat is de kortste, helderste uitleg van deduplicering die ik ooit heb gezien.
Ik had het niet beter kunnen zeggen.

Zfs doet het blokgebeuren inderdaad op zo'n soort manier.
NAS dozen van NetApp en EMC trouwens ook.

Meestal worden er trouwens per blok/file2 hashes gebruikt die op verschillende manieren worden berekend. Dit verkleint de kans op een "collision" (== 2 blokken met verschillende inhoud maar gelijke hash waarde) gigantisch zelfs als beide hashes vrij weinig bits gebruiken.

[Soldaatje]

Ik snap er nog steeds niks van, maar toch bedankt voor de moeite.

[Verwijderd]

Dit soort voordelen vindt je ook terug in moderne SAN apparatuur. Ik hoop in de toekomst dit soort features ook terug te zien in andere bestandsystemen (Dedup FTW)

[]Byte[]

SDFS - www.opendedup.org
Ik kan je helaas nog geen ervaringscijfers geven omdat ik nog mee bezig ben om deze in een VM te bouwen om te testen.

@ matty____ hieronder:
Nou dat is wel heel veel. Met sdfs heb je 33 bytes per chunk (bij 4k chunksize) nodig.
Dan heb je voor een 200GB disk ca. 1,65 GB mem. nodig Bij een chunksize van 8k heb je dus nog maar de helft nodig. Je moet alleen wel ff opletten dat wanneer je de disk wilt gebruiken voor VMware (VMDK's) dat je dan alleen 4k chunksize mag gebruiken.
Als ik zie welke snelheden ze (opendedup.org) realiseren op de testomgeving moet ik zeggen dat dit er toch wel acceptabel uitziet. (Ja, daar spreken ze van een config waar 12 GB inzit, maar daarvan had ie maar 2GB nodig)

Here are the results of the 1st Run, Copying Unique Data into SDFS:

128k Chunk Size = 290 MB/s
64k Chunk Size = 265 MB/s
32k Chunk Size = 248 MB/s
4k Chunk Size = 89.9 MB/s

[Reactie gewijzigd door ]Byte[ op 29 juli 2024 09:59]

[Verwijderd]

Dedup is zeker leuk als je het geheugen er voor hebt.

hoorde ergens iets van 12gb plus extra log ssd voor fatzoenlijke performance

[Verwijderd]

Maar goed, dat is in een zakelijke omgeving natuurlijk geen enkel probleem.

Lijkt me toch wel erg mooi, 10 mensen bewaren 10 versies van een excel sheet en het totale storage beslag is naar verwachting maar een paar keer de gemiddelde grootte van de sheet.

[johnbetonschaar]

Bied ZFS voor de normale sterveling zoals ik extra voordelen t.o.v Ext4 ?

Heel erg weinig. Zoals hieronder hierboven al opgelepeld zitten er allerlei erg boeiende features in ZFS, maar een normale sterveling is beter af met zoiets als ext4 plus een extra HDD voor periodieke backups. ZFS wordt pas interessant voor systemen met veel schijven erin. Qua performance is ext4 ook sneller voor een huis-tuin-en-keuken systeem.

[Reactie gewijzigd door johnbetonschaar op 29 juli 2024 09:59]

[Verwijderd]

ligt eraan hoe belangrijk je je data vind.

freebsd met 4 schijven op zfs is prima voor thuis.

en de benchmarks die je af en toe ziet vind ik altijd wel grappig. zfs met alle features aan vs. ext4 waar alles wat het traag zou kunnen maken uit staat. met name phoronix heeft daar een handje voor.

hoe betrouwbaar heel het zaakje is staat dan natuurlijk weer niet in de benchmark.

zolang je met meer dan 100 mb/s (1gb/s nic) naar je nas kunt schrijven is het toch prima.

[johnbetonschaar]

ligt eraan hoe belangrijk je je data vind.

freebsd met 4 schijven op zfs is prima voor thuis

Zelfs dan nog biedt het relatief weinig voordelen ten opzichte van hetzelfde systeem met 4 schijven met een redundante RAID opstelling, dan is je data net zo veilig maar ben je wel een stuk sneller klaar met alles installeren en configureren. Natuurlijk kan je met ZFS allerhande complexe setups maken die anders niet mogelijk zijn, maar de vraag was of je daar als 'normale' thuisgebruiker veel aan hebt. Ik denk dat het de moeite niet waard is.

[Sfynx]

Zelfs dan nog biedt het relatief weinig voordelen ten opzichte van hetzelfde systeem met 4 schijven met een redundante RAID opstelling, dan is je data net zo veilig

Wat ZFS uniek maakt is het detecteren (en bij een redundant pool ook corrigeren) van stille corruptie. Ja, dit komt voor, bitjes blijven heel soms niet staan. Wanneer dit voorkomt in je storage systeem, zal ext4 dit dan opmerken, of gewoon de foute informatie gebruiken?
Bij ZFS weet je op z'n minst altijd of je gegevens goed zijn, omdat elk blok wordt gechecksumd, en gecontroleerd bij het inlezen. Kan je leuk testen door bij een ZFS RAID setup expres bagger direct naar 1 van de schijven te schrijven en vervolgens bestanden op die locaties proberen te lezen... zal je zien dat je gewoon correcte info terugkrijgt en de betreffende locaties weer worden gerepareerd, met checksum mismatches in de poolstatistieken.
Bij niet redundante pools krijg je dan een I/O fout. Maar nooit foute informatie

Dit alles zal het vast wel wat trager maken, ZFS is inderdaad vrij CPU en RAM onvriendelijk vergeleken met andere bestandssystemen. Voor mij is dat me wel waard voor mijn server, in ruil voor weer een iets betere nachtrust.

P.S: Veel RAID systemen bieden trouwens geen bescherming tegen de zogeheten "write hole" waardoor parity sweeps nodig zijn na crashes... ZFS is transactioneel en heeft dat probleem ook niet. De enige eis is dat de write caches op de schijven eerlijk zijn over wanneer de data op de platter staat.

[Reactie gewijzigd door Sfynx op 29 juli 2024 09:59]

[Xthemes.us]

Ik heb eens m'n (software) raid array om zeep geholpen door deze naar een andere systeem te verplaatsen toen het moederbord het loodje had gelegd.

Als dat bij ZFS wel goed gaat dan heb ik er wel oren naar.
Heeft BTRFS hier ook een optie toe, of als iemand de juist zoektermen hier voor zou ook handig zijn.

[Sfynx]

Als dat bij ZFS wel goed gaat dan heb ik er wel oren naar.

Een ZFS pool kan je zelfs verplaatsen tussen verschillende architecturen, en van big-endian naar little-endian block pointers en omgekeerd (ZFS kan beide vormen gebruiken door elkaar en draait het om wanneer nodig). Dus bv van Solaris op SPARC naar FreeBSD op x86 zou prima werken.

Pool exporteren, en op nieuwe machine weer importeren en gaan maar weer.

[Reactie gewijzigd door Sfynx op 29 juli 2024 09:59]

[Verwijderd]

Heb je het eigenlijk ooit gebruikt onder freebsd/solaris en snap je uberhaupt wat zfs is? volgens mij niet namelijk...

# zpool create tank raidz da0 da1 da2 da3

en klaar is kees(binnen 2 sec) voor een raid5 setup

[Reactie gewijzigd door Verwijderd op 29 juli 2024 09:59]

[Verwijderd]

zolang je met meer dan 100 mb/s (1gb/s nic) naar je nas kunt schrijven is het toch prima.

Ik vind dit wel een erg korte termijn visie. Met de ontwikkelingen in dataland (grootte van opslag media, de mogelijkheden om data te verplaatsen, en de hoeveelheid devices die data verplaatsen) zou ik me niet blindstaren op _slechts_ 100MB/s

Daar komt bij dat er al genoeg Nas devices zijn met dual Gbit nics. Ik denk dat het niet erg lang meer zal duren tot 10Gbit geintroduceerd zal worden in consumenten Nas devices.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 09:59]

[Verwijderd]

dual nics in een 2 disk nas van netgear zeker ben benieuwd of die ook 2gbit kan wegschrijven

je nas groeit toch met je mee mits je geen kant en klare hebt of ben ik nou gek

[Reactie gewijzigd door Verwijderd op 29 juli 2024 09:59]

[Elmo_nl]

Dat hangt er van af hoe je het wil gaan gebruiken. Kijk hier maar eens naar de (on-)mogelijkheden van dit filesystem: http://nl.wikipedia.org/wiki/ZFS

[Verwijderd]

Vervelend aan ZFS is dat je een storage pool niet kleiner kan maken. M.a.w. als je een schijf wil vervangen kan dit alleen met een groter of gelijk exemplaar. Wil je naar een kleinere pool dan zul je een nieuwe pool moeten creeren. Dit is vooral voor thuisgebruik vervelend omdat de meeste mensen niet zomaar een paar extra schijven hebben liggen.

Men heeft dit (het oplossen van dit probleem) wel op de wishlist staan (al jaren) maar het wordt blijkbaar door de ontwikkelaars niet als een groot probleem gezien.

Afgezien van dit soort puntjes zijn er toch geen serieuze onmogelijkheden bij ZFS?

[Verwijderd]

waarom zou je een schijf met een kleiner exemplaar willen vervangen?

zelfde grootte is toch prima

[wankel]

Dat is toch al jaaaren de trend in harddisk-land? Telkens maar kleinere schijven voor hogere prijzen neerzetten? ;-)

[Azzmodan]

Ik heb wel gehad dat een vervangende schijf van "de zelfde grote" net 1 of 2 megabyte kleiner was, en dat is dan toch behoorlijk onprettig.

[Verwijderd]

omdat niet op file niveau gaat maar op block.

[Verwijderd]

Ik snap niet hoe dat deze nieuwe implementatie wel compatibel is met de GPL. Of is het zo dat ze de kernel module uit de 'hoofd'kernel kunnen houden waardoor er niets geïntergreerd hoeft te worden? Maar zelfs in dat geval zullen Debian en Ubuntu ZFS niet meeleveren omwille van de licenties.

[Little Penguin]

Als je zelf de broncode compileert, dan heb je geen last van de GPL-beperking. Alleen mag je de gecombineerde code niet verspreiden, want een combinatie van GPL+CDDL is niet compatible...

Verder is Ubuntu niet zo strikt m.b.t. open source guidelines en zou, als het legaal is gewoon ZFS opnemen in de distributie.

[MsG]

Wat zijn nou eigenlijk de botsende clausules in deze licentievormen?

[humbug]

GPL dwingt af dat elk afgeleid werk als open source verspreid wordt. CDDL staat toe dat afgeleide werken als closed source kunnen worden verspreid.

Deze beperking van de GPL (extra eis in de licentie) maakt dat gebruik van CDDL code in GPL projecten illegaal is. Net zoals bv code die onder de BSD licentie en Apache Licentie vallen niet in GPL projecten gebruikt kunnen worden.

[The Zep Man]

Deze beperking van de GPL (extra eis in de licentie) maakt dat gebruik van CDDL code in GPL projecten illegaal is. Net zoals bv code die onder de BSD licentie en Apache Licentie vallen niet in GPL projecten gebruikt kunnen worden.

Het kan wel gebruikt worden. Echter, degene die het allemaal combineert mag het resultaat alleen zelf gebruiken en niet meer verspreiden. Er is dus niets mis mee om het voor een intern project/product te gebruiken.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 09:59]

[Verwijderd]

Toch zie ik het onder de CDDL nog niet verschijnen als optie bij de installatie. De 'basic' ubuntu is relatief strikt in termen van open source. Dat het beschikbaar is, akkoord. Maar of het de standaard wordt betwijfel ik. Zonde, want ZFS is een heel geavanceerd file system.

[arjankoole]

Ik snap niet hoe dat deze nieuwe implementatie wel compatibel is met de GPL. Of is het zo dat ze de kernel module uit de 'hoofd'kernel kunnen houden waardoor er niets geïntergreerd hoeft te worden? Maar zelfs in dat geval zullen Debian en Ubuntu ZFS niet meeleveren omwille van de licenties.

Ze hebben altijd de 'non-free' (in elk geval Ubuntu) repository, waarin de 'tainting' modules hun huis gevonden hebben. Daar vind je ook de nVidia modules bijvoorbeeld. (die vanwege license restricties niet opensource gemaakt kunnen worden, en daarom deels in binary vorm worden geleverd door nVidia)

[Yggdrasil]

Precies. Je zult het zelf moeten inladen in je kernel. Vergelijkbaar met de binary blob drivers van Nvidia, etc.

[Elmo_nl]

Dat staat in het artikel: Via een omweg, een implementatie via het Fuse-project, kan zfs weliswaar in userspace legaal worden gedraaid, maar deze methode heeft prestatieverlies tot gevolg.

[aequitas]

Deze implementatie maakt dus geen gebruik van die omweg, maar bouwt ZFS direct in als kernel module.

[MsG]

Dat was juist de voormalige oplossing. Dit artikel gaat over een nieuwe oplossing waarbij die workaround niet meer hoeft.

[35MHz OC]

Of is het zo dat ze de kernel module uit de 'hoofd'kernel kunnen houden waardoor er niets geïntergreerd hoeft te worden?

Dit schijnt inderdaad het geval te zijn. De CDDL blijft incompatible met de GPL, dus een gecompileerde Linux kernel met reeds gekoppelde ZFS module distribueren is er niet bij.

Lijkt me dat dit het commerciele gebruik van "native" ZFS voor Linux een stuk onaatrekkelijker maakt.

[Verwijderd]

Het probleem ligt eigenlijk bij GPL . CDDL staat gebruik voor vanalles toe maar als je software bakt met GPL, moet deze software ook GPL worden. Als je jouw software wilt toevoegen aan de kernel, zal je calls e.d. maken naar stukjes GPL code in de kernel. Dit mag je van GPL alleen doen als jouw software een licentie heeft die minstens zo vrij is als GPL. CDDL valt daar niet onder, dus mag CDDL software zoals ZFS geen GPL code gebruiken zoals de Linux kernel.

[blouweKip]

Volgens mij is het toch echt een beperking van de cddl, die is minder vrij dan de GPL waardoor het moeilijker is deze te gebruiken zoals je dat als gebruiker/programmeur zou willen.
Het is dus maar hoe je het bekijkt...

[humbug]

De GPL staat niet toe dat andere code met GPL code communiceert. Lijkt me duidelijk welke licentie hier de beperking heeft.....

En over meer/minder vrij kunnen we ook wel een boom opzetten. De GPL dwingt af dat afgeleide werken ook GPL zijn. Dat houdt de code vrijer dan de CDDL waarbij afgeleide werken closed source kunnen worden. Tegelijkertijd heb je als ontwikkelaar meer vrijheid om de toekomst van je eigen project te kiezen bij de CDDL. Denk je dat je afgeleide project beter af is met een Closed Source implementatie staat de CDDL dat toe. De mate van vrijheid hangt dus af van waar je staat en geen van beide is minder vrij dan de andere. Men heeft enkel voor andere vormen van vrijheid gekozen. En daar is niets mis mee. Dat noemen we keuzevrijheid.

GPL fans moeten leren niet bij alle problemen rondom de GPL naar anderen te wijzen. De virale eigenschappen van de GPL zijn in veel gevallen prettig maar staan ook duidelijk integratie met andere producten in de weg. Dit is het zoveelste bekende voorbeeld.

[cibrhusk]

Je punt is als ik het goed lees dat GPL te viraal wil zijn. Dat dit integratie met andere producten vaak in de weg zit is logisch omdat de GPL vooral een ideaal is. Als je idealen laat compromitteren dan raken ze vervuild en sterven vaak uiteindelijk een stille dood.

Wat de GPL volgens mij vooral wil bereiken is dat alles altijd vrije open source is, nu en in de toekomst. Het is duidelijk dat de CDDL het hier niet mee eens is, maar voor mij is het ook duidelijk dat CDDL dan ook geen echt ideaal voor staat. Het is wel open, maar het nodigt uit om vooral niet terug te koppelen en de boel lekker weer te sluiten, dat komt de ontwikkeling van de hoofdmoot dus niet ten goede.

Overigens zie ik niet in waarom je niet een dual licentie regelt, als de CDDL meer toestaat dan de GPL, dan zou het geen probleem mogen zijn,

[djc]

Ik wacht lekker op btrfs, dat gemiep met de ZFS is volgens mij de moeite niet waard zolang Oracle niet expliciet ZFS vrijgeeft (onder de GPL).

[Verwijderd]

Het verschil tussen ZFS en BTRFS is dat de eerste vrijwel uitontwikkeld is en de 2e nog ongeveer de alfa status heeft. Als je op het internet rondkijkt lijkt er momenteel ook niet veel te gebeuren met BTRFS (behalve dat het meegeleverd wordt in Linux). Ik denk dus dat dat heel lang wachten wordt.

[BCC]

De implementatie van ZFS op Solaris is inderdaad volledig uitontwikkeld, maar voor linux heb je op dit moment alleen een FUSE implementatie die zeker niet volledig is. En nu is er dus een splinternieuwe kernel module implementatie.

Je hebt wel gelijk dat de ZFS specificatie al is uitgekristaliseerd, maar de ZFS implementatie op linux staat op dit moment meer in de kinderschoenen dan BTRFS. Daarnaast heeft ZFS inderdaad ook nog eens licentieproblemen.

[humbug]

BTRFS is niet veel meer dan een kloon van ZFS. En voorlopig nog een heel stuk verwijderd van de mogelijkheden van ZFS.

Ondanks dat er nu een partij is die een kernel module heeft gebouwd die zo meegeleverd kan worden wil je liever tijd in een slechte kopie (BTRFS) steken dan gewoon het originele project ondersteunen. Lijkt me nou niet echt zinvol. De linux gemeenschap moet leren om te gaan met andere Open Source licenties. De GPL is zeker niet heilig en software onder licenties als BSD, Apache en CDDL zou gewoon goed in Linux geïntegreerd moeten kunnen worden. Maar ja, men doet blijkbaar liever dubbel werk.

[CAPSLOCK2000]

Er zijn nu dus twee ZFS implementaties voor Linux die allebij nog te jong zijn om echt te vertrouwen. Zelfs als nu blijkt dat deze code supergoed is geschreven en geen enkele fout bevat, dan nog zal het een jaar duren voor iemand het echt durft te gebruiken. Tegelijkertijd wordt er ook stevig doorgewerkt aan BTRFS dat in ieder geval al de zegen van de kernel developers heeft gekregen. Het wordt steeds spannender welk FS als eerste productieklaar is (op Linux) ZFS of BTRFS.

[Verwijderd]

de ZFS code is production het gaat alleen om de implementatie met linux.

bij btrfs is de code nog lang niet beta.

[CAPSLOCK2000]

Duh, maar als je het op Linux wil gebruiken zit je dus vast aan code die nog niet voldoende praktijkervaring heeft gehad, daar gaat het om.

[Verwijderd]

Tegelijkertijd wordt er ook stevig doorgewerkt aan BTRFS ...

Heb jij misschien een bron hiervan? Volgens mij gebeurt er het laatste jaar qua ontwikkeling namelijk heel weinig.

[Verwijderd]

Hoewel zfs nu beschikbaar komt als kernelmodule voor Linux, is het onduidelijk of KQ Infotech in de toekomst geld voor zijn creatie wil zien.

Dat zal moeilijk zijn. De enigste mogelijkheid is support c.q. aanpassingen op betaling.
Voor de rest is binnen GPL alle code vrij bruikbaar voor de gene die de binary ooit aangeschaft hebben.

[Yggdrasil]

Let op: de module heeft geen GPL licentie maar CDDL. De module zal dan ook niet in de kernel meegeleverd worden, maar kan later ingeladen worden, vergelijkbaar met de Nvidia driver blobs, of de VMware Tools.

[Verwijderd]

Let op: de module heeft geen GPL licentie maar CDDL. De module zal dan ook niet in de kernel meegeleverd worden, maar kan later ingeladen worden, vergelijkbaar met de Nvidia driver blobs, of de VMware Tools.

Dit mocht en mag niet.

Het is niet voor niets dat VMWare de VMware Tools onder GPL vrijgegeven heeft.

Zie ook deze link van forbidden items.

Om deze reden verwacht ik dat als de code geen GPL is dat deze een flop wordt.
Er staat bijna geen Linux gebruiker te wachten op grijze/zwarte Linux code tav een file systeem.

Bij Videodrivers is dit waarschijnlijk door de vingers gezien omdat er geen andere optie was.

Ik verwachte dat dit een eigen ZFS implementatie was van KQ Infotech die GPL zou worden.

Het is aangepaste openSolaris ZFS code?

[Reactie gewijzigd door Verwijderd op 29 juli 2024 09:59]

[The Zep Man]

[...]


Dit mocht en mag niet.

Ik citeer uit de Executive Summary:

The law is unsettled as to the validity of this practice, and while some industry leaders believe it complies with GPL, others do not.

Zolang het wettelijk niet getoetst is, kan niet geconcludeerd worden of iets legaal of illegaal is.

Het is niet voor niets dat VMWare de VMware Tools onder GPL vrijgegeven heeft.

Dat is ook makkelijker voor VMWare: zo hoeven ze zelf geen onderhoud er meer op uit te voeren. Het is niet alsof daar hele diepe bedrijfsgeheimen in verborgen zijn.

Zie ook deze link van forbidden items.

Dit is appels met peren vergelijken. Fedora is een distributie welke afhankelijk is van vrije code. Tegelijkertijd kan je niet closed spul meeleveren i.c.m. de GPL. Modules welke niet met de kernel of met een distributie meegeleverd worden zijn het onderwerp.

Om deze reden verwacht ik dat als de code geen GPL is dat deze een flop wordt.

De Nvidia display driver is een flop?

Er staat bijna geen Linux gebruiker te wachten op grijze/zwarte Linux code tav een file systeem.

Een ervaren Linux-hobbyist die voor zichzelf hiermee aan de slag gaat kan toch zo mooi ZFS toevoegen aan zijn NAS. Bedrijven kunnen dit ook voor zichzelf gebruiken, zolang het maar niet gedistribueerd wordt buiten het eigen bedrijf.

Bij Videodrivers is dit waarschijnlijk door de vingers gezien omdat er geen andere optie was.

Er zijn altijd opties. Alleen gebruikers willen uitgebreide 3D acceleratie welke GPL-licensed drivers niet (altijd/op tijd) kunnen leveren.

En dit kan heel gebruiksvriendelijk worden gemaakt. Een ander voorbeeld zijn de originele Microsoft TrueType Core Fonts. Debian heeft in de 'Contrib' repository een open-source, GPL script staan genaamd ttf-mscorefonts-installer welke de fonts van het internet haalt en op de gebruiker zijn/haar machine installeert. De reden dat deze in de 'Contrib' repository staat is om te voorkomen dat non-GPL code ongewild op de machine van de gebruiker geïnstalleerd wordt, ondanks dat het script van Debian zelf onder de GPL valt. Debian ziet er streng op toe dat alle code in de 'main' repository onder de GPL valt en niet zomaar non-GPL code/modules kan ophalen.

Wat de OSS community zou moeten doen is een clean-room design van de originele implementatie van Sun/Oracle maken. Op die manier is er 100% compatibiliteit en het resultaat kan wel onder de GPL verspreid worden.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 09:59]

[Sfynx]

De vraag is dan wel hoe stabiel de interface met de Linux kernel blijft, aangezien ze daar niet zomaar source kunnen veranderen speciaal voor hun ZFS implementatie lijkt me.

Bij FreeBSD is ZFS ook geïmplementeerd als een aparte module (eentje voor ZFS, en eentje voor gedeelde OpenSolaris code aangezien ze ook DTrace hebben), maar dan door het FreeBSD team zelf en weet ik niet hoeveel ze aan de rest van de kernel hebben gezeten om het mogelijk te maken.

[arjankoole]

Het voordeel van kernelmodules is dat je heel makkelijk eenvoudig de kernel kunt uitbreiden zonder dat je in de kernel zelf moet wroeten. als je wel in de kernel moet gaan harken om je module aan de gang te krijgen doe je iets goed fout(tm) en schiet je jezelf best in de voet.

[bzerk]

Verlicht mij: hoe wil jij bv Dtrace implementeren (het tracen/tracken van alle mogelijke syscalls) dmv 1 enkele loadable module zonder in de rest van de kernel code te "harken"?

[Tiny]

Knowledge Quest Infotech is toch een Indiaas bedrijf?

[Verwijderd]

Indisch moet inderdaad Indiaas zijn...

[Phoenix_the_II]

Foutjes kan je hiero melden na de link klik:

http://gathering.tweakers.net/forum/list_messages/1418631

[84hannes]

offtopic:
Geef een man een vis...

Hoewel ik je hulp waardeer, denk ik dat het niet zo'n constructieve manier is iedere keer de link naar het forum te plaatsen nadat mensen een fout hebben gemeld in het reactieveld. Liever vertel ik mensen hoe ze het forum kunnen vinden

Rechts van het artikel vind je de Feedback knop. Als je hierop klikt kom je in het forum om fouten te vermelden.