Nieuwe organisatie wil ontwikkeling zfs-bestandssysteem sturen

Een aantal ontwikkelaars heeft OpenZFS opgericht, een organisatie die sturing moet geven aan de verdere ontwikkeling van het zfs-bestandssysteem. Het opensource-bestandssysteem wordt onder andere gebruikt op Linux, FreeBSD, OS X en illumos.

OpenZFS heeft naar eigen zeggen drie primaire doelstellingen. Als eerste wil de non-profitorganisatie de kwaliteit en bruikbaarheid van het zfs-bestandssysteem garanderen, onder andere door documentatie voor ontwikkelaars en systeembeheerders te gaan schrijven. Ten tweede moet OpenZFS een discussieplatform vormen voor developers die het bestandssysteem ontwikkelen. De website en een nieuwe mailinglist moeten daarbij helpen.

Volgens de organisatie zijn er in de laatste jaren te veel forks ontstaan en de derde doelstelling is daarom de code van zfs zo te optimaliseren dat deze eenvoudiger tussen verschillende besturingssystemen is uit te wisselen. Daarvoor moet onder andere crossplatform-testsoftware worden ontwikkeld.

OpenZFS heeft de goedkeuring gekregen van Matt Ahrens, een van de oprichters van het geavanceerde bestandssysteem dat bij het voormalige Sun is ontwikkeld. Op de projectenpagina van OpenZFS wordt overigens gemeld dat de aangesloten developers, naar schatting iets meer dan honderd, werken aan een Raspberry Pi-versie van het filesystem en dat zfs beter moet gaan functioneren in combinatie met virtual machines.

Reacties (71)

[KirovAir]

reviews: Opslagnetwerken met zfs en Comstar

Nog een zeer informatief en bijpassend artikel van onze eigen Femme.

[Reactie gewijzigd door KirovAir op 26 juli 2024 15:43]

[hakariki]

http://xkcd.com/927/

[Ultraman]

Heeft weinig met een nieuwe "standaard" van doen. ZFS is een volwassen filesystem en samenwerking er omheen is er al. De bedoeling hier is om de ontwikkeling van ZFS te centraliseren onder OpenZFS, in plaats van dat de main tree in Illumos zit.

[ATS]

Niet relevant lijkt me. Dit gaat niet over de one standard to rule them all, dit gaat over een project om gedivergeerde code bases weer bij elkaar te brengen, en niet door daar een nieuwe code base naast te zetten als ik het zo lees.

[johnkeates]

Dat heeft dan weer niks met dit te maken. Wat hier nu eigelijk gebeurd is, is dat er 1 standaard is, en meerdere forks voor bepaalde distributies, om dat die ene standaard nergens automatisch werkt en dus voor DEB-systemen, RPM-systemen, Unix-achtigen en Solaris-achtigen stuk voor stuk 'gepatcht' moet worden.

Hoewel ZFSonLinux al een eind op weg was, is het gewoon niet te doen zonder centrale 'governance' over het gehele project.

ZFS is namelijk niet zomaar in een bestaand project op te nemen, om dat de licentie vrij vaak (mutueel) exclusief is, wat er voor zorgt dat je het niet zomaar in je 'main' project kan meeleveren.

Door OpenZFS te stichten krijg je een soort van centrale voor ZFS, waar alles en iedereen dat met ZFS te maken heeft zich bij aan kan sluiten. Dat zorgt er uiteindelijk voor dat alle ZFS-functies nu niet meer stuk voor stuk geporteerd moeten worden, maar dat er 1 ZFS is, (m.u.v. Oracle's versie), en dat alle distributies hun eigen versie van dat hoofdproject kunnen overnemen.

Dus stel dat je Ubuntu en Red Hat hebt, dan zitten die nu nog met ZFS on Linux, en een tussenlaag (meestal hun eigen repo beheer) voordat het in je distro te installeren is. Met OpenZFS zal je dan 1 ontwikkelclub hebben (waar je natuurlijk nog steeds patches naartoe kan sturen) maar voor elke distributie de juiste packaging en toevoegingen. Een beetje zoals Apache. Er is maar een Apache, maar er zijn per distributie standaarden en elementen toegevoegd die voor die distributie relevant zijn. Uiteindelijk draai je altijd dezelfde software, maar dan binnen je eigen omgeving.

[BugBoy]

Het is jammer dat Apple niet heeft doorgezet met de invoering van ZFS op OS X. Het staat dan wel in het artikel dat er ook ZFS voor OS X is, maar dat is niet waar. In 2008 kondigde Apple aan dat ZFS in de volgende versie van OS X zou komen. Dat zou een geweldige stap voorwaarts zijn geweest, want HFS+ is antiek. In 2009 is men daar op teruggekomen en heeft Apple ZFS weer laten vallen.

ZFS heeft snapshotting op een erg elegante wijze in het filesysteem geimplementeerd. De Time Machine functionaliteit had daar perfect op gepast. Nu is het erg gekunsteld, maar met ZFS hadden ze het veel eleganter kunnen implementeren.

Apple (zoals altijd) heeft er geen commentaar op gegeven. Algemeen wordt verondersteld dat de licentie van ZFS (CDDL) wellicht voor problemen had kunnen zorgen. Het feit dat Sun door Oracle was overgenomen heeft het waarschijnlijk ook niet bespoedigd (ZFS vindt zijn oorsprong in Solaris dat door Sun is ontwikkeld).

De CDDL licentie is ook de reden geweest waarom ZFS onder Linux geen succes is geworden. Die licentie sluit niet goed aan bij de GNU licentie die voor Linux wordt gebruikt. Onder andere om die reden is daar de ontwikkeling van BTRFS gestart.

ZFS heeft overigens ook nog wel wat tekortkomingen. Vooral het niet kunnen toevoegen van extra schijven aan bestaande pools vind ik een misser. Technisch lijkt het mij niet zo heel ingewikkeld, maar zover ik weet zit dat er nog altijd niet in.

Verder is ZFS een prachtig bestandssysteem. Voor kleine (embedded) devices is het niet geschikt. Het vereist wat meer geheugen (vooral als je deduplication wilt gebruiken) dan veel traditionele filesystemen. Je krijgt er alleen wel wat voor terug. Ik gebruik trouwens naar volle tevredenheid ZFS op mijn FreeBSD server (2GB RAM en met een 10TB ZFS pool).

[matty___]

ZFS heeft overigens ook nog wel wat tekortkomingen. Vooral het niet kunnen toevoegen van extra schijven aan bestaande pools vind ik een misser. Technisch lijkt het mij niet zo heel ingewikkeld, maar zover ik weet zit dat er nog altijd niet in.

Als het technisch niet zo moeilijk was dan zat het er al lang in

[Sfynx]

Schijven toevoegen aan pools kan wel, gewoon een nieuwe vdev erbij hangen. Schijven toevoegen aan vdevs is een ander verhaal, de feature die dit mogelijk moet maken (block pointer rewrite) is een soort vaporware geworden inmiddels, wellicht komt het er ooit nog eens echt van

[Dreamvoid]

Apple (zoals altijd) heeft er geen commentaar op gegeven. Algemeen wordt verondersteld dat de licentie van ZFS (CDDL) wellicht voor problemen had kunnen zorgen.

Apple is Apple - die hebben de centen en de juridische expertise om die problemen gewoon in overleg op te lossen. Ze werken al met Oracle samen in OpenJDK, bijvoorbeeld, hun belangen overlappen nauwelijks.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 15:43]

[BugBoy]

Het is natuurlijk mogelijk dat men dat achter de schermen heeft geprobeerd, maar daar (financieel) niet is uitgekomen. Feit is dat Apple ooit de plannen had om HFS+ op te laten volgen door een moderner bestandssysteem en dat op een gegeven moment toch gestopt is. Er lijken geen technische redenen te zijn (er is ook een MacZFS project dat het prima schijnt te doen), dus er moet een andere reden zijn.

Vriend en vijand is het er over eens dat HFS+ niet meer van deze tijd is en dat ZFS prima in het OS X plaatje zou passen. Voorheen maakte Apple veel gebruik van standaard functionaliteit. De laatste tijd zie je dat minder worden. Samba is in Lion ook vervangen door een Apple's eigen SMBX implementatie.

Wellicht dat het e.e.a. te maken heeft dat sommige software van de GPLv2 naar de veel striktere GPLv3 licentie gaat, waardoor het lastig commercieel is te gebruiken. Dat zou erg jammer zijn, want dan fragmenteert de markt nog meer. Het zou erg fijn zijn dat een ZFS pool onder FreeBSD ook probleemloos onder Linux, OS X en Windows zou werken.

[matty___]

Volgens mij kun je de pools zonder problemen tussen verschillende OSen uitwisselen

[BugBoy]

Dat zal waarschijnlijk wel kunnen, maar voor veel besturingssystemen moet je allerlei trucen uithalen om ZFS te kunnen gebruiken.

[matty___]

Bij FreeBSD zit het standaard bij. Bij Linux is het ook zo geinstalleerd. OSX en Windows hebben geen echte ports dus die vallen beetje af.

Maar tussen OpenSolaris, Freebsd en Linux is het geen probleem

[BugBoy]

Dat is dan ook de reden dat ik FreeBSD draai op mijn NAS. Bij Linux vind ik het een beetje een zo-zo oplossing, omdat het geen native filesysteem is. Ik heb liever een filesysteem die bij mijn kernel geleverd wordt. Dan weet je redelijk zeker dat je geen compatibiliteitsissues krijgt.

[Maurits van Baerle]

ZFS is er op dezelfde manier voor OS X als het er voor Linux is. Er is geen standaard ondersteuning in/rond de kernel (niet meer sinds 10.6, het zat wel read-only in 10.5) maar er zijn wel projecten die ZFS voor OS X leveren. Net als ZFS niet in de Linux kernel zit maar wel afzonderlijk te installeren is.

Een van de bekendste versies van ZFS voor OS X is die van Don Brady, hij was bij Apple verantwoordelijk voor ZFS en heeft daarna z'n eigen bedrijf opgericht dat ZFS naar OS X heeft gebracht. Hij heeft later de krachten gebundeld met een ander bedrijf met dezelfde doelstelling en daar is Zevo uit voort gekomen. Daarnaast zijn er ook community projecten zoals zfs-osx die het naar OS X hebben geport.

Ik verwacht dat zodra de licentieperikelen van ZFS zijn opgelost zowel Linux als OS X het standaard kunnen integreren.

[Sfynx]

Time Machine en ZFS zou echt geweldig zijn ja, een backupsessie is dan een snapshot maken in een seconde en een zfs send stream overtrekken en op een andere schijf receiven. Dit gecombineerd met de in de praktijk niet bestaande limieten in ZFS betekent dat je nog veel vaker dan eens per uur een backup kan maken. Verder zorgen verschillen binnen bestanden er niet voor dat een compleet bestand compleet opnieuw wordt gekopieerd, alleen de gewijzigde blokken binnen een bestand maken deel uit van de nieuwe snapshot. Dat kan enorm veel ruimte besparen als er bijvoorbeeld virtual machine images worden gebackupt.
Snapshots verwijderen is ook een kwestie van seconden, dat zou een verademinig zijn vergeleken met de tijd die het kost om nu backups te 'cleanen' op een TM drive.
En je backups kunnen nooit ongemerkt corrupt raken of half afgemaakt worden, want snapshotting is een atomische operatie.

Kortom, gemiste kans, heel erg jammer. Misschien komt het er ooit nog eens van.

[Reactie gewijzigd door Sfynx op 26 juli 2024 15:43]

[arjankoole]

Apple (zoals altijd) heeft er geen commentaar op gegeven. Algemeen wordt verondersteld dat de licentie van ZFS (CDDL) wellicht voor problemen had kunnen zorgen. Het feit dat Sun door Oracle was overgenomen heeft het waarschijnlijk ook niet bespoedigd (ZFS vindt zijn oorsprong in Solaris dat door Sun is ontwikkeld).

Apple heeft ZFS laten vallen omdat er destijds - en ik dacht nog steeds - een patentzaak loopt tussen netapp en sun (nu Oracle) mbt tot ZFS. Als dat niet had gespeeld was HFS al in lion vervangen geweest voor ZFS.

[Thulium]

Wat ik me alleen afvraag, los van het feit dat keuzevrijheid een groot goed is, waarom zou je ZFS over BTRFS kiezen, of andersom.

Voornamelijk omdat ik tot nu alleen artikeltjes gezien heb waar een van de twee de hemel wordt ingeprezen en de ander afgefakkeld wordt.

[OMX2000]

Volgens mij is BTRFS nog steeds niet volwassen. Ik hou het een heeeel klein beetje in de gaten omdat ik het liefst Linux draai op mijn NAS en dan is ZFS a no go. Maar de afgelopen twee jaar check ik phoronix eens in de 6 maanden om te zien hoe het zich verhoudt to anders filesystems, maar met name performance blijft achter in vergelijking met XFS of Ext4.

[Sfynx]

Het ligt ook helemaal aan de schaal waarop je iets opzet. Op kleine systemen met relatief weinig power is ZFS in het nadeel omdat er een hoop extra checks en berekeningen plaatsvinden zodat je gegevens nooit ongemerkt kapot kunnen gaan. Ext4 is een veel lichter bestandssysteem.

ZFS schaalt echter veel beter op grote disk arrays vergeleken met Ext4+LVM, het is dan ook hét opslagsysteem bij uitstek voor grote storage bakken. Ik zou het persoonlijk nooit gebruiken op een systeem met minder dan 4 GB RAM, en eigenlijk wil je altijd ECC geheugen hebben om corruptie ook op dat niveau tegen te gaan (afhankelijk van waar het plaatsvindt kan ZFS je niet altijd tegen memory errors beschermen)

[Reactie gewijzigd door Sfynx op 26 juli 2024 15:43]

[Xudonax]

Je hebt gewoon ZFS on Linux wat goed stabiel draait hoor Draai het zelf al ruime tijd op Fedora 17/18/19. Kijk eens in het grote ZFS topic op het forum als je dat nog niet gedaan had.

[ilaurensnl]

Klopt, ZFS is toch iets trager dan hardware raid of in dergelijke, en zfs heeft veel ram nodig anders werkt het niet bepaald soepel.

Zelf heb ik raid 1 met ZFS voor mijn thuis nasje(4gb ram, nas4free), werkt super, +/- 80 mbps r/w.

Zelf heb ik niks te klagen daarover

[ilaurensnl]

Lijkt mij leeftijd, ouder betekend vaak minder bugs, BTRFS heeft een redelijk lange tijd instabiel gedraait maar dat is inmiddels al verholpen, en is BTRFS ook een goede oplossing voor een filesysteem.

Zo ver ik weet is BTRFS beter voor SSD, en ZFS voor gewone schijven en maakt gebruik van veel RAM Caching en zo ver ik me kan herinneren kan je tegenwoordig ook een SSD gebruiken als cache voor veel gelezen bestanden.

[Sfynx]

Btrfs is nog steeds experimenteel en bij lange na niet feature stable, laat staan dat het allemaal lang genoeg getest is. Als je ergens conservatief moet zijn, is het wel op het gebied van file systems.

[ilaurensnl]

Klopt, maar zo ver ik weet is Btrfs nu stabiel, althans dat staat op Wikipedia. En daarmee ben ik mee eens, file systeem is erg belangrijk en natuurlijk wil je geen stabiliteit issues of corrupt data daardoor krijgen, en helemaal niet op servers.

[Mr_gadget]

Dit zou ZFS wel een goede boost kunnen geven. Het maakt het porten naar andere OS' en wat makkelijker.

ZFS voor de raspberry pi lijkt me niet heel handig aangezien je niet heel makkelijk raid arrays op een Raspberry pi maakt. Maar misschien network based of voor educatie. Of usb stick array.

[Ultraman]

ZFS kunnen gebruiken op een Raspberry Pi lijkt mij best handig. En denk ook aan de toekomst, dit is ZFS op een ARM doosje, en dit opent mogelijk de weg voor ZFS op andere machines met de ARM instructieset. Zuinig servertjes bijvoorbeeld.

Daarnaast is Btrfs een Linux only fs, ik vind het nog niet fijn werken, en het is nog steeds onstabiel. Terwijl ik ZFS al in 2 jaar in gebruik zonder problemen heb en de tools ook aardig ken. Ik heb ook een externe harddisk waar backups op staan, waarop nu JFS als filesystem is gebruikt. Stel ik zou een Raspberry Pi in willen zetten als backup doosje, dan kan ik daar dankzij dit project wellicht die grote USB disk aan hangen met ZFS, en gebruik maken van snapshots en "zfs send" om snapshots vanaf de server naar toe te kopiëren als backup. Ja, een vrij specifieke use case, maar voor wie al ZFS gebruikt en zoiets wilt doen is dit best handig.

ZFS is trouwens ook te gebruiken met weinig RAM, alleen kun je dan niet flink aan caching doen. Ja, dat zal wat gevolgen hebben voor de performance, en op dit moment is 512MB RAM + ZFS mogelijk nog wat onhandig. Maar wie weet maakt dit project het ook echt bruikbaar. En snelheid is lang niet altijd het meest relevant, integendeel. Waarom denk je dat ik ZFS gebruik? Niet voor de snelheid kan ik je vertellen, maar voor de integriteit.

[Reactie gewijzigd door Ultraman op 26 juli 2024 15:43]

[kidde]

"ZFS op Linux" draait al op ARM, zie ZFS projectenpagina waarnaar gelinkt wordt in het artikel.

[Ultraman]

Ik kan er maar weinig over vinden maar het lijkt inderdaad zo te zijn. De performance kan ik nog minder over vinden, maar wat ik kan vinden geeft aan dat het nog niet optimaal is. ARM is er daarnaast in vele varianten, daar is vast nog ruimte voor testing met verschillende platformen, waaronder dus de Raspberry Pi.

[ilaurensnl]

Voor ZFS is caching belangrijk, zonder cache kan je er beter niet aan beginnen, 512 mb voor de raspberry is dus een no go.

Voor de rest is het een super bestandsysteem, gebruik ik ook voor mijn thuis nasje

[_Thanatos_]

Ik heb een NAS die in principe ook ZFS kan, maar de interface om het te maken (is dat het goeie woord?) is nogal verwarrend. Maar als jij zegt dat 512MB te weinig is (aangenomen dat je MB bedoelde) dan gaat het sowieso niet werken, want mijn NAS heeft dus 512MB geheugen...

Heeft de jouwe meer dan dat? Hoeveel dan, en hoe snel is ie?

[martijnnos]

Er was ergens iemand die zei 1GB Ram per TB Data opslag, en over het algemeen minimaal echt wel 4GB.

Het hoe wat waarom weet ik niet precies meer maar komt er gewoon opneer dan 512MB (bijna) altijd te weinig zal zijn.

[Reactie gewijzigd door martijnnos op 26 juli 2024 15:43]

[_Thanatos_]

Hoe kan het dan dat mijn 8TB NAS (5x2TB in RAID5) met 512MB geheugen zo snel is? Dan is ZFS dus performance-wise zwaar ondergeschikt aan Ext3, als het waar is wat die persoon zei. Ik gebruik Ext3 en ik trek m'n gigabit LAN helemaal tot iets over de 100MB/s, beide kanten op.

Het zo ook niet verwonderlijk zijn dat ZFS sneller wordt met meer cache, want cache is geheugen en geheugen is sneller dan een disk. Maar ik zou het werkelijk wonderbaarlijk slecht vinden als ZFS alléén snel is met zo belachelijk veel cache, en traag zonder. Ik hoop van harte dat het niet waar is, maar als dit zo is, dan is ZFS wat mij betreft een klotesysteem.

[Reactie gewijzigd door _Thanatos_ op 26 juli 2024 15:43]

[martijnnos]

Ik weet niet hoeveel er van waar is, nog niet zelf getest.

Maar ik vind snelheid niet zo erg interessant, zolang snel genoeg , ZFS bied alleen andere voordelen en die vind ik veel belangrijker. Ik haal daarnaast met NTFS ook 100MB/s vanaf 1 schijf via netwerk, maar ik denk dat juist caching goed kan helpen voor een hoop IO. Misschien zit ik er volledig naast.

Ik denk dat er erg veel voordelen zitten aan ZFS mits je krachtige hardware gebruikt, wat in mijn ogen ook geen probleem hoeft te zijn. Ligt net aan het doel wat je voor ogen hebt.

[_Thanatos_]

Bestanden heen en weer schuiven*, meer eigenlijk niet. Wel veel kleine bestandjes, dus het moet niet zo door de war raken dat het op een gegeven moment traag wordt... Iets wat in de Windows-wereld gecorrigeerd kan worden met een defragger.

*) wat doe je anders met een NAS

[Reactie gewijzigd door _Thanatos_ op 26 juli 2024 15:43]

[johnkeates]

Ik denk dat het niet een 'boost' krijgt. (wat bedoel je met boost? dat ie 'harder' gaat?) Ik denk wel dat ZFS updates eerder in distro-specifieke repo's terecht komen.

ZFS voor zo veel mogelijk architecturen lijkt me wel handig, zodat je het bijvoorbeeld ook met een flinke HAVP firewall of ADC kan gebruiken die misschien niet op x86 draait, of ARM, maar PowerPC ofzo. Gewoon dat ZFS overal werkt. En misschien op den duur zonder spl kan.

[Mr_gadget]

Een boost in de ontwikkeling, adaptatie en het aantal architecturen waarop het kan draaien

[johnkeates]

De ontwikkeling wordt er niet anders van lijkt me, gezien het dezelfde developers zijn als dat er al waren Het aantal architecturen wordt ook niet meer, adaptie verandert ook niet.. dus dat is het niet.

Misschien dat je zou kunen zeggen dat de snelheid waarmee patches van distro's upstream worden meegepakt een boost krijgt. Maar dat is maar een klein boostje..

[Superstoned]

Probleem is en blijft dat het grootste en meest relevante besturingssysteem, Linux, geen ZFS gaat krijgen wegens de incompatibiliteit van de licentie van ZFS.

btrfs is het enterprise linux bestands systeem van de toekomst - en dat betekend dus gewoon het bestandssysteem van de toekomst. Jammer van ZFS maar tenzij dat GPL wordt gaat dit niet veranderen.

[arjankoole]

Dat licentie probleem is wel om heen te werken. ZFS kun je dan nog altijd installeren en activeren waar dat relevant is. (De meeste machines kunnen prima met ext4 draaien, en zodra het stabiel is bevonden, btrfs).

Voor grote storage filers, is ZFS een prima keuze, en daar praat je via isci, nfs, etc tegen aan met Linux. Helemaal geen probleem dus.

[u_nix_we_all]

ZFS on Linux (ZoL) is anders flink in opkomst. Dit is een native implementatie van ZFS, in tegenstelling tot ZFS-Fuse die de CDDL-gelicenseerde code gebruikt, en daarom alleen omder FUSE kan werken.

Als ik lees dat ze een echte open-source implementatie willen maken, denk ik dat deze juist op de ZoL code gebaseerd zal zijn.

Wat dat betekent voor BSD en illumOS, die nu wel de CDDL-gelicenseerde code gebruiken, weet ik nog niet.

Hoe dan ook, ik denk dat het een positieve ontwikkeling is. De race tussen ZFS en btrfs is nog lang niet gelopen.

[Verwijderd]

Het probleem is NIET open source. Want ZFS IS open source. Het gaat erover dat de CDDL licentie een patent-pool bevat. En patenten, daar moet je omheen werken als je het GPL wil maken. Anders komt het sowieso NIET in de standaard kernel. Ik zie dat nog NIET gebeuren. Btrfs is de toekomst voor mainstream Linux.

[u_nix_we_all]

Je hebt gelijk dat CDDL ook een open source licentie is, maar ZoL is dus een GPL implementatie, en die zit misschien nog niet in de standaard kernel maar ik verwacht dat dat zeker nog gaat komen.

[Durandal]

Ik draai het nu een jaartje en het is vooralsnog een ideaal filesysteem gebleken. Wel hoop ik dat ze het uitbreiden van de ZPools mogelijk gaan maken want dat mist het in vergelijk met bv. een normale raid en maakt het voor de prive gebruiker ook een stuk toepasbaarder.

[Sfynx]

Ja, de inmiddels mythische "block pointer rewrite" feature moet er eens in komen. Daar hebben ze het al jaren over op de mailinglists en het komt iedere keer weer boven drijven, maar daar houdt het steeds mee op.

Je kan een zpool nu al wel uitbreiden, maar alleen door alle schijven in een bestaande vdev te vergroten, of door er een nieuwe vdev aan te hangen. Het aantal schijven in een vdev veranderen (bijvoorbeeld twee schijven in een raidz2 erbij hangen), dat kan niet... maar met die nieuwe feature zou dat wél kunnen.

Het zou ook online defragmentatie (ja als je pool te vol wordt kan je daar gewoon lats van krijgen), online recompression/deduplication en online rebalancing mogelijk maken. Dat laatste is bijvoorbeeld handig als je een vdev erbij hangt in een volle pool, dan wil je eigenlijk dat alle data opnieuw verdeeld wordt over alle schijven voor optimale striping performance. Dat kan nu niet, dan zou je alle gegevens in de pool moeten verplaatsen.

[Reactie gewijzigd door Sfynx op 26 juli 2024 15:43]

[Verwijderd]

Persoonlijk had ik gehoopt dat je het filesystem in een cluster (dus gedistribueerd) kunt gebruiken, maar als ik de documentatie bekijk kan dat niet. Erg jammer. Een gemiste kans. Nu moet je er weer een clustered filesystem bovenop bouwen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 15:43]

[Ultraman]

zpools uitbreiden kan gewoon hoor. Je kunt prima vdevs toevoegen aan een pool.
Je kunt vdevs niet uitbreiden, dat is voor sommigen wel eens vervelend. Maar het is niet echt een beperkende restrictie, want je kunt vdevs toevoegen aan een pool. Voeg schijven dus in setjes toe als je wilt uitbreiden. Pak bijvoorbeeld twee schijven en voeg ze als mirror toe, of drie als raidz, of nog meer. Ik ben zo van een single mirror naar een striped mirror gegaan, geen enkel probleem en direct meer capaciteit.
Daarnaast kun je binnen een vdev ook oude schijven vervangen voor grotere, en zodra je alle disken van vdev hebt vervangen kun je expanden. Op het moment gebruik ik nog steeds 1.5TB schijven, waarvan er al twee ooit vervangen zijn binnen de garantie. Mocht er een disk slecht worden dan vervang ik deze voor een grotere. De kans dat er een andere binnen afzienbare tijd dan ook slecht wordt is best groot, gezien de gelijke leeftijd, en die vervang ik dan ook voor een grotere. Zorg ik gewoon dat de twee nieuwe disken in dezelfde vdev komen, dan heb ik gelijk meer capaciteit.
Als je raidz gebruikt dan zit je met meer schijven, en dan zul je meer schijven moeten vervangen. Dat is een beperking die je eigenlijk jezelf hebt opgelegd.
Maar als je meer capaciteit nodig hebt kun je prima een mirror toevoegen.

[thunderlight]

zou het fijn vinden als Microsoft ook eens gaat kijken naar een ander bestands systeem dan de NTFS die zij al jaren hanteren.
Daar NTFS Niet echt een van de snelste bestandssysteem is.

[StefanTs]

ReFS?

[Dreamvoid]

ZFS is ook niet de snelste, snelheid is zelden het belangrijkste criterium. Ik vermoed dat het bij MS een gevalletje "if it aint broke dont fix it". De server business is de afgelopen jaren enorm gegroeid, dat willen ze denk ik niet riskeren door een nieuw filesystem te introduceren. Idem met Linux overigens, de grote Linux vendors maken de transitie naar btrs en zfs bijzonder langzaam.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 15:43]

[tenpo]

storage pool in W8

[RoestVrijStaal]

Maar onder welke licentie gaat het vallen? CDDL zoals bij Oracle's ZFS-implementatie?

Ik denk dat het het meest levensvatbaar zou zijn onder de LGPL, 3-clause-BSD of MIT.

[Dreamvoid]

Oracle heeft de latere versies van ZFS niet meer onder CDDL gepubliceerd.

[Loen]

Volgens mij is openzfs alleen een organisatie om de verschillende ports onder te laten vallen. ZFS valt nog steeds onder de CDDL licentie, dus de ports zijn dat allemaal ook en als er een "OpenZFS ZFS variant" bij komt is dat ook gewoon CDDL. Alleen Oracle kan daar eventueel nog iets aan doen. (ik zou heel graag ZFS on Linux zien (kernel implementatie, dus niet via FUSE en ook niet van zfsonlinux.org))

[onox]

zfsonlinux.org is juist een kernel implementatie. Je kan het installeren als module, maar je kan het ook handmatig toevoegen aan je kernel (als je zelf een kernel aan het configureren bent):

Op Gentoo gaat dat zo:

env EXTRA_ECONF='--enable-linux-builtin' ebuild /usr/portage/sys-kernel/spl/spl-0.6.2.ebuild clean configure
(cd /var/tmp/portage/sys-kernel/spl-0.6.2/work/spl-spl-0.6.2 && ./copy-builtin /usr/src/linux)
env EXTRA_ECONF='--with-spl=/usr/src/linux --enable-linux-builtin' ebuild /usr/portage/sys-fs/zfs-kmod/zfs-kmod-0.6.2.ebuild clean configure
(cd /var/tmp/portage/sys-fs/zfs-kmod-0.6.2/work/zfs-zfs-0.6.2/ && ./copy-builtin /usr/src/linux)

Gewoon ff ./configure en daarna ./copy-builtin /usr/src/linux dus. Je mag je kernel dan alleen niet meer verder verspreiden aan andere mensen.

[beerse]

Dat zfs bij Oracle wordt losgeweekt verbaast mij niet. Dat is met meer zaken gebeurt.

Dat ze zfs op de raspberry-pi willen poorten verbaast me wel. Die heeft alleen maar 1 sd kaartje, 1 of 2 usb poorten, 0 of 1 netwerk aansluiting en 0.25 of 0.5 GB memory... Niet echt een platform om een nas op te zetten. Maar het kan mij verrassen, XBMC speelt ook zonder problemen de mooiste films.

[Dreamvoid]

ZFS wordt niet zozeer van Oracle losgeweekt, als wel op klassieke open source manier geforked. Vanaf ZFS v28 (Pool) en v5 (FS) is Oracle in zijn eentje verder gegaan met ZFS in Solaris 11, en zit inmiddels op v34 en v6. De projecten die er nu zijn voor Linux, BSD, etc. zijn allemaal implementaties van v28/v5, en voor de toekomst zal OpenZFS een nieuwe koers voor dit filesystem moeten kiezen.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 15:43]

[Snow_King]

OpenZFS is daarom ook met pool versie 5000 begonnen om zo nooit in het vaarwater van Oracle te zitten.

[piccollo1985]

Ik hoop dat openzfs onder een andere licentie uitkomt dan CDDL die compatibel is met de GPL.

[BugBoy]

Even als toelichting... Dat zou ZFS breder toepasbaar maken en dan zou het ook opgenomen kunnen worden in de Linux kernel.