Software-update: OpenZFS 2.1.10

Het opensource zfs-bestandssysteem werd oorspronkelijk door Sun ontwikkeld voor Solaris maar in 2013 heeft een aantal ontwikkelaars OpenZFS opgericht om de verdere ontwikkeling te waarborgen. Het bestandssysteem wordt momenteel officieel ondersteund op Linux en FreeBSD. Het bevat onder andere methodes om datacorruptie in zowel de data als de metadata te voorkomen, biedt dataredundantie via RAID-Z en spaart ruimte door de data transparant te comprimeren. Voor meer informatie verwijzen we jullie door naar de OpenZFS-website. De ontwikkelaars hebben versie 2.1.1 uitgebracht en hierin zijn de volgende veranderingen en verbeteringen aangebracht:

Supported Platforms

• Linux: compatible with 3.10 - 6.2 kernels
• FreeBSD: compatible with releases starting from 12.2-RELEASE

Changes

• Removed Python 2 and Python 3.5- support #12925
• linux 6.3 compat: needs REQ_PREFLUSH | REQ_OP_WRITE #14695
• Fix "Add colored output to zfs list" #14712
• ZTS: Log test name to /dev/kmsg on Linux #13227
• Add Linux kmemleak support to ZTS #13084
• Linux 6.2 compat: META #14689
• Fix console progress reporting for recursive send #14448
• zfs_main.c: fix unused variable error with GCC #14441
• Use setproctitle to report progress of zfs send #14376
• Additional limits on hole reporting #14512 #14641
• Add colored output to zfs list #14621 #14350
• Colorize zpool iostat output #14621 #14459
• Add more ANSI colors to libzfs #14621
• linux 6.3 compat: add another bdev_io_acct case #14658 #14668
• Update vdev state for spare vdev #14653
• zed: add hotplug support for spare vdevs #14295
• zed: post a udev change event from spa_vdev_attach() #14172
• zed: mark disks as REMOVED when they are removed
• FreeBSD: Remove extra arc_reduce_target_size() call #14639
• Improve arc_read() error reporting
• QAT: Fix uninitialized seed in QAT compression #14632 #14463
• Fix for mountpoint=legacy #14599 #14604
• ZFS_IOC_COUNT_FILLED does unnecessary txg_wait_synced() #13368
• Update workflows
• Workaround GitHub Action failure #14530
• Ubuntu 22.04 integration: GitHub workflows #14148
• initramfs: fix zpool get argument order #14572
• Turn default_bs and default_ibs into ZFS_MODULE_PARAMs #14293
• Add missing increment to dsl_deadlist_move_bpobj() #14573
• Optimize the is_l2cacheable functions #14494 #14563
• System-wide speculative prefetch limit. #14516
• Prefetch on deadlists merge #14402
• Introduce minimal ZIL block commit delay #14418
• Pack zrlock_t by 8 bytes #14317
• Remove few pointer dereferences in dbuf_read() #14199
• Switch dnode stats to wmsums #14198
• Micro-optimize zrl_remove() #14200
• Remove atomics from zh_refcount #14196
• Optimize microzaps #14039
• autoconf: add support for openEuler #14241
• Set DEFAULT_INIT_SHELL to /sbin/openrc-run for Gentoo and Alpine #12683 #12692
• rpm: add support for openEuler #14222
• Revert zfeature_active() to static
• Move dmu_buf_rele() after dsl_dataset_sync_done() #14522 #14523
• Partially revert eee9362 #14502
• Fix a race condition in dsl_dataset_sync() when activating features #13816
• initramfs: Make mountpoint=none work #14455
• Avoid a null pointer dereference in zfs_mount() on FreeBSD #14218
• Allow mounting snapshots in .zfs/snapshot as a regular user #13758

Versienummer	2.1.10
Releasestatus	Final
Besturingssystemen	Linux, BSD
Website	OpenZFS
Download	https://github.com/openzfs/zfs/releases/tag/zfs-2.1.10
Licentietype	GPL

Reacties (41)

[rob12424]

Wat is tegenwoordig nog het voordeel van zfs tegenwoordig tegenover btrfs?

[N8w8]

Wat ik zie van btrfs is dat het regelmatig bugs heeft.
Bijv hier hier hier hier hier wat recente bugs, of hier n mooi (incompleet) historisch overzicht.
Ik zie dat overigens omdat ik al 10(?) jaar altijd en overal btrfs gebruik en mn ervaring is dat het buggy is, dus houd ik het wel beter in de gaten dan andere filesystems.
Over ZFS hoor ik nooit van zulke erge bugs (mss wel andere problemen, die vaak ook lijken te liggen aan config/hardware/user, maar tenminste geen bugs in het fs zelf).
Ja en btrfs RAID is ook niet bepaald geweldig zoals al gezegd is. Dus in plaats daarvan gebruik ik het bovenop lvmraid, goed genoeg voor mij, maar niet zo fancy als ZFS.
En het werkt niet op FreeBSD.

[Reactie gewijzigd door N8w8 op 23 juli 2024 09:39]

[syl765]

Naar wat ik weet is vooral het raid gedeelte in btrfs nog niet op het nivo van ZFS.
Dus voor een enkele disk setup is het prima te gebruiken. Ga je echter de raid opties gebruiken dan zou je wel eens van een koude kermis thuis kunnen komen.

[Tivoler]

Smaak.

[Marve79]

Geweldig bestandssysteem. Jarenlang op Freebsd gebruikt, toen de switch naar Linux gemaakt. En steeds mn disks met data gewoon mee kunnen nemen naar nieuwe hardware en ander besturingssysteem. Nooit corrupte data gehad.

[blorf]

Nog steeds niet goed geprobeerd. Ik zat te denken aan zo'n 10-poort SATA 3 kaart vol te hangen met alle mech schijven die ik nog heb. Kun je dan ook 6GB/s halen met alles in een ZFS pool? Ik heb een keer een experiment met USB 2.0 sticks op een enkele roothub gedaan, maar dat slibt helemaal dicht door het cachen. Een kaart met 10 USB-controllers zou ook kunnen maar die heb ik nog niet gezien.

[Reactie gewijzigd door blorf op 23 juli 2024 09:39]

[Ariejan]

Dit SATA kaarten werken vaak maar matig. Wat ik veel zie (bij enthusiaste hobbyisten) is 'n LSI Raid kaart met 'n IT-mode firmware flashen. Met 2x SAS kun je dan al 8 SATA schijven rechtstreeks en individueel aanspreken. ZFS vind dat heerlijk.

[WeiserMaster]

Met een beetje zoeken vindt je dat soort kaarten met SAS 12GBPS/SATA 6GBps (SATA3) voor 50 euro. Soms al met IT mode geflasht.

Ook af en toe op Tweakers in V&A

Een korte guide over de verschillende types:
https://www.servethehome....cks-truenas-freenas-hbas/

[Ithaca81]

En met een beetje pech zijn dat precies de fake kaarten waar eBay vol mee staat en is het gissen naar de kwaliteit … de tijd dat je ‘even’ een hba kan kopen is er niet meer.

https://forums.servetheho...8-ebay-counterfeit.36154/

[polycombGC]

Volgens mij zijn de 10 poorten van een dergelijke kaart niet tegelijkertijd aan te spreken. Er zijn intern minder poorten in (bijv 2), daarachter zit een multiplexer om tot 10 poorten te komen. Je kan daardoor zo'n kaart niet voor ZFS gebruiken omdat alle schijven daarvoor tegelijkertijd benaderd moeten kunnen worden.

[blorf]

Geen idee hoe dat werkt. Wat krijg je aan devices erbij? Bij zo'n complete RAID-kast als IcyBox wordt het in FreeBSD een enkel /dev/ada? device omdat dat apparaat alles zelf regelt.
Je moet natuurlijk geen ding kopen die gewoon een soort SATA-hub is.
De echte zijn redelijk prijzig. 10 poorten gaat richting de 150 euro.

[SilentDecode]

ZFS moet de disks direct aan kunnen spreken, dus een RAID-controller is zwaar afgeraden. Als je toch veel poorten nodig hebt, kan je dus een HBA gebruiken, wat in principe alleen een signaalomvormer is. Deze gaat van SAS (dat SATA backwards compatibel is) naar PCIe en zorgt ervoor dat ZFS de disks direct kan benaderen zonder verdere software er tussen.

[ScharlakenRood]

ZFS heeft controle nodig over de cache op elke disk om 100% zeker te zijn dat de data op permanente storage zit. Met een tussenliggende RAID controller met eigen cache is ZFS nooit zeker wat nu permanent weggeschreven is. Indien je een RAID controller in je systeem hebt zitten moet je die dan ook in pass-through mode zetten. Sommige RAID controllers laten dit niet toe.
ZFS gebruikt het geheugen van het systeem als cache ipv door een RAID controller (zoals de meeste FS), doch de opbouw van ZFS zorgt er wel voor dat dit efficient gebeurt en IO operaties in block gebeuren. Op dit moment kan ZFS ook beslissen om per disk de disk cache te gebruiken tot er een effectieve data commit moet gebeuren.
Heb in al de jaren (>10) dat ik met ZFS werk (op Solaris) nog nooit data verloren. De eenvoud om met ZFS te werken en zelfs om disks (ttz zpools) te verplaatsen van systeem zullen elke LLVM gebruiker direct overtuigen.
Enkel bij gebruik van een RAID controller onder ZFS heb ik ooit problemen ondervonden omdat de cache op de RAID ctrl het heeft laten afweten met data corruptie tot gevolg. Gelukkig was de schade beperkt tot een aantal files die door ZFS scrub snel werden opgepikt en van een backup moesten gehaald worden.

[johnny2000]

En als je JBOD gebruikt in je RAID controller? Want zo heb ik in het verleden wel zaken gedaan in ZFS

[The Zep Man]

En als je JBOD gebruikt in je RAID controller? Want zo heb ik in het verleden wel zaken gedaan in ZFS

Dat kan nog steeds cache gebruiken.

Je wilt zoveel mogelijk simpele 'AHCI'-aansluitingen hebben. Dan kan de disk direct door het OS aangesproken worden, zonder tussenliggend cache.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:39]

[blorf]

Het moet natuurlijk ook gewoon tegen stroomuitval kunnen.Opslag die afhankelijk is van wat zich nog in hardware-cache bevindt is nooit een goed idee. Is een hardware-RAID niet zo in te stellen dat het die cache zsm gaat verwerken bij idle time? ZFS zou de schijf-cache wat mij betreft als RAM kunnen gebruiken als dat snelheidswinst oplevert, maar ga er aub niet van uit dat de data daarin permanent is opgeslagen. Dat is gewoon niet zo.

[Reactie gewijzigd door blorf op 23 juli 2024 09:39]

[Dutchtraveller]

Het is waarschijnlijk een 2 poorts Sata controller met op elke Sata poort een 1->5 multiplexor.
De multiplexor kan een van de 5 disks die erop aangesloten zijn doorverbinden met de Sata-controller.
De theoretische maximum snelheid is ongeveer 2x550=1100MB/s maar verwacht daar niet veel van.
Die multiplexor veroorzaakt overhead, het schakelen tussen de kanalen moet ook worden aangestuurd.
Ik heb het wel eens geprobeerd maar het was traag en niet betrouwbaar.

Lijkt leuk en goedkoop maar ik zou zo'n controller niet kopen.

[Willempie27]

Als je meerdere schijven tegelijk wilt gebruiken is zo'n goedkope kaart niet aan te bevelen. Ik heb een 10 of 12 poort kaart en dat gaat redelijk goed. Maar met unraid een check uitvoeren gaat met slechts met 25Mb/s. De onboard sata poorten zijn een betere keuze.

[blorf]

Wat is het verschil? DIe onboard SATA-controller zit toch op dezelfde bus? Alleen is die misschien door lab-testen beter afgestemd op de rest van de hardware, en de bedrading naar de CPU is waarschijnlijk korter.
Wat ik zou willen is een backup-systeem met een kaart en schijven die het hele aanvoerkanaal vol kan krijgen zonder dure opslag-hardware die individueel zo hoog mogelijk probeert te scoren.
SATA 3 is theoretisch 6Gb/s. 3Gb/s transfer in de praktijk zou al heel mooi zijn om bijv. dagelijks op de achtergrond 2TB of 100 miloen bestanden te backuppen.

[Dutchtraveller]

Je kunt beter een kaart kopen op basis van de ASM1166 controller.
Die controller heeft 2 PCIe v3 lanes en 6 Sata poorten.

Ze zijn te koop bij amazon.nl
De kaarten zijn zowel in x4 als in x1 fysieke uitvoering te koop (wel goed kijken naar de plaatjes want de beschrijvingen zijn vaak niet zo helder).
X4 sloten heb je meestal maar 1 van, maar x1 sloten soms meerdere.

Zelfs in een x1 uitvoering haal je max 1GB/s en dat is genoeg om 6 HDD's aan te sturen.
Wil je meer disken of meer snelheid, koop dan 2 kaarten met x1 aansluiting en verdeel je array over 2 controllers.

[blorf]

35 euro? Staat zelfs of Ali. Waar is een PCIe x4 10 poort SATA kaart voor rond de 150 euro dan goed voor?

[niqck]

Kan ik alleen maar be-amen. Vanaf de 1e beta's gebruik op Solaris, mijn eerste NAS gebouwd met FreeNAS en ZFS en verder ge-upgrade. Nog geen bit data kwijt geraakt. Disks stuk per stuk vervangen door grotere exemplaren en dan de zpool laten groeien...

Het concept is iets anders dan bij klassieke LVM maar o zo flexible.

Ik heb in mijn ganse carriere van ZFS (+20 jaar) nog maar 1 keer een echte corruptie gemerkt. Een klant had in een cluster de zpool op 2 nodes (geforceerd) ge-importeerd. Gegarandeerd koekenbak natuurlijk als die beiden op de disken beginnen te schrijven.

[Dutchtraveller]

Ik heb voorheen veel met mdadm gewerkt en dat was een drama.
Als ook maar iets gebeurde met het array dan kreeg je het niet meer goed ondanks proberen van allerlei tips van internet. In het beste geval was je maar 1 disk kwijt en kon je resilveren maar vaak was het weg data.
Ik heb met ZFS meegemaakt dat meerdere disken van een array geen power hadden.
Het array werd niet gemount. Je sluit de ontbrekende disken aan en start opnieuw op.
Voila ZFS detecteert wat er mis is gegaan en fixt zelfstandig de problemen.
Een andere keer viel een SSD uit, na powercycle werkte hij weer en ZFS repareerde de blokken waar een probleem mee was.
En als er ooit iets onherstelbaar corrupt raakt dan kan zfs je vertellen welke files het betreft.
Dan hoef je alleen die files te restoren van je backup.

Met de nieuwe versies heb je ook support voor encryptie en efficiënte compressie.
Je kunt je data backuppen naar een andere server (met zfs-send) zonder te decrypten of uncompressen.
De backup server heeft dus geen toegang tot de data.

Het enige wat ZFS (nog) niet heeft is het vergroten van een bestand array met een extra disk.
Er is een poging geweest dit toe te voegen maar daar zitten nog problemen in.
Wat wel kan is een extra array toevoegen aan een bestaande pool.

[Reactie gewijzigd door Dutchtraveller op 23 juli 2024 09:39]

[Sfynx]

De native ZFS encryptie moet ik nog eens naar kijken, had het tot nu toe altijd via een ZFS pool bestaande uit GELI volumes (een FreeBSD full disk encryptiemethode binnen hun GEOM systeem) gedaan. Als je dan de boel zfs send naar een andere machine is het alsnog unencrypted, dus dat encrypted kunnen doen zonder dat aan de backup server kant dat gelezen kan worden klinkt zeer interessant.

Ik gebruik ZFS al sinds dat het onderdeel werd van FreeBSD, en ik heb nog nooit gegevens verloren door een probleem wat aan ZFS zelf lag. Het enige incident was toen bij een pool bestaande uit een drietal mirrors tijdens een resilver van een schijf juist de andere schijf in die mirror een rotte sector kreeg. Wat daar stond was ik dus kwijt, en zpool status vertelde me precies welk bestand ik moest oprakelen uit mijn backup Verder geen downtime, gewoon een i/o error op die ene file

Het werkt nu overigens ook best aardig out of the box op 2 of 4 GB RAM configuraties, een tijd geleden had je nog weleens wat extra tweaks nodig om dat stabiel te krijgen. Voor performance wil je wel gewoon 8 GB of meer zodat ie lekker kan cachen

[Dutchtraveller]

Wat ZFS en encryptie betreft kan ik je onderstaand artikel van Jim Salter aanraden:
https://arstechnica.com/g...penzfs-native-encryption/

Hij heeft al meer over ZFS geschreven en ook tools ontwikkeld om snapshots te maken en te syncen.

[Tivoler]

Als je data via mdadm kwijt bent geraakt weet je niet wat het is of hoe het werkt. ZFS is een bestandsysteem, mdadm niet. Je verhaal over 2 disken klopt niet, al je gewoon ext3/4 (desnoods met LVM) draait tussen twee disken via Raid1 is het letterlijk een kopie welke mdadm draait. Je lijkt een holy grail gevonden te hebben met ZFS maar ook ZFS heeft zijn issues welke klaarblijkelijk nog niet hebt ondervonden omdat je gewoon geen poweruser bent en blij bent als "iets" werkt maar doet alsof je het dagelijks administreert.

[pennywiser]

Ik herken dat van MDADM niet, ik gebruik het nu meer dan 15 jaar. Soms voor storage nog best handig. Maar niettemin ben ik ook naar ZSF aan het kijken, echter ook daar zie ik wel de nodige valkuilen.

[GeroldM]

Zelfde hier. Ook een software RAID5 opgezet via mdadm, zo'n 15 jaar terug. Dat werkt best goed en betrouwbaar. Maar het voelt tegenwoordig ook wel "oudbollig" aan. Alternatieven, zoals ZFS en BTRFS klinken steeds beter en vooral moderner.

mdadm is niet zo heel moeilijk (met een RAID5 opstelling), maar een probleem oplossen kan heel snel veel tijd in beslag nemen. En dat is mijns inziens een groot nadeel. Misschien dat ZFS net zo problematisch is, maar dat lijkt me niet. Dat is tot op heden mijn mening en moet ik misschien aanpassen nadat ik er afdoende mee heb zitten "spelen".

[damouze]

Als voormalig Solaris systeembeheerder heb ik in het verleden aardig wat ervaring opgedaan met ZFS en nog steeds gebruik ik sporadisch ZFS voor privédoeleinden.

Ik vond (en vind) het echter wel een mes dat aan twee kanten snijdt: enerzijds is het conceptueel geweldig en best wel briljant, anderszijds is het concept ook niet zonder nadelen.

Een belangrijk nadeel van ZFS vind ik toch wel de verwarring tussen volume management en filesystem management. ZFS maakt dat onderscheid niet (althans niet op dezelfde manier als bijv. LVM dat doet). Naar mijn mening is dat toch wel een nadeel omdat het verwarring schept bij de mensen die ermee moeten werken.

Het klassieke concept is je maakt één of meer partities of slices aan, voegt deze toe aan een array en vervolgens maak je op die array een fileystem aan of je voegt deze toe aan een volumegroep om vervolgens daarin een logical volume aan te maken voor een filesystem. Het onderscheid tussen filesystems en alles wat daaronder aan de basis ervan ligt is duidelijk. Het is daarnaast ook nog eens enorm flexibel en die flexibilteit mis ik nog wel eens bij ZFS.

Ik heb thuis een storage systeem met 6 disks, ieder opgedeeld in een aantal partities. Een deel van die partities zit in md RAID6 arrays (in het verleden RAID5, maar na een keertje in de mist gegaan te zijn met een disk die kapot ging terwijl ik een reeds kapotte disk aan het vervangen was ben ik overgestapt) en een ander deel zit in md RAID10 arrays. Ik kan makkelijk schuiven met partities wanneer mijn behoeften veranderen en doordat de partities vergeleken bij de disks zelf betrekkelijk klein zijn (bijvoorbeeld 250GB), zijn eventuele rebuild times van een individuele array bij een crash veel korter dan wanneer alles in een enkele array zou zitten. Daarbovenop zit een systeem van volumegroepen en logical volumes. De performance van dit geheel is best okay. Goed genoeg voor wat ik ermee doe, zeker gezien het feit dat een groot deel van de logical volumes via ISCSI worden aangeboden aan een hypervisor.

Uiteraard had ik dit natuurlijk ook kunnen doen via iets als FreeNAS or TrueNAS, maar de lol zat hem voor mij vooral in het zelf bouwen van zo'n systeem ;-).

[ScharlakenRood]

Voor de old-school systeem administrators kan het inderdaad verwarrend overkomen. Je moet een zpool van disks aanmaken waar je je data redundantie bepaalt. Eenmaal je bijvoorbeeld een zpool hebt van bv 5TB kan je daarin een [bijna] onneindig aantal 5TB ZFS in aanmaken. Elk ZFS in de zpool is een startpunt van blokken die je reserveert voor dat FS dat dan gebruik kan maken van eigen functies als compressie, encryptie of dedup. Je moet het zien als een dynamisch FS binnen een pool. Je moet er ook absoluut voor zorgen dat je onder de 90% vullingsgraad blijft van je zpool wat zorgt dat je nooit al je disken 100% kan vullen. Klinkt als een nadeel. maar in het oude model moet je ook altijd 5% vrijlaten per FS om een goede werking te waarborgen. Bij ZFS is het 10% op de pool (ttz op al je disks die erin zitten)

[damouze]

Ik ben bijzonder gecharmeerd van de dedup faciliteiten van ZFS, zonder meer.

En zeker binnen de context van iets als een NAS of een SAN is het een topoplossing.

[Dutchtraveller]

Dedup vergt veel RAM, m.i. omdat de hashes van alle bestanden in het RAM moeten worden bijgehouden om dedup mogelijk te maken.

[Dutchtraveller]

Ik heb ervaring met allerlei bestandssystemen en wat mij betreft is ZFS het beste wat ik tot nog toe gezien heb.
Vroeger deelde je een disk op allerlei partities zoals boot, root, var, home, opt etc maar dat is niet flexibel. Als je ergens ruimte te kort kwam had je een probleem...
Het gebruik van een zpool bij ZFS voorkomt dat soort problemen. Je hoeft je niet druk te maken over de verdeling van de ruimte en dat scheelt een boel tijd.
ZFS hoeft bij een crash alleen die blokken te repareren waar een probleem is opgetreden dus dat is ook snel en zelfs automatisch na een reboot.

ZFS is anders maar ik vindt de integratie die ZFS biedt juist erg handig.
Een belangrijke focus van ZFS is data-integrity, voor mij heel belangrijk.
Een ook features als geïntegreerde caching, compressie en encryptie zijn erg handig.
Kijk eens naar de artikelen van Jim Salter en zijn tooling voor snapshot management.

[Reactie gewijzigd door Dutchtraveller op 23 juli 2024 09:39]

[damouze]

Ik denk dat we dan ongeveer dezelfde ervaring hebben. Het was ook zeker niet mijn bedoeling om ZFS in een kwaad daglicht te stellen. Ik vind het zelf ook geweldig, ook al gebruik ik het niet zoveel in mijn dagelijks werk of privé.

In het verleden had ZFS nog wel wat tekortkomingen als het ging om features. Eén van de features die ontbraken en op grond waarvan ZFS op mijn werk niet massaal werd ingezet in de tijd dat ik nog meer dan 20 uur per week datacenter en Linux/Unix systeembeheer deed was het ontbreken van de ondersteuning voor DirectIO. Aangezien dat een vereiste was voor het database platform dat wij gebruikten, viel ZFS voor ons af als basis voor de Solaris containers die we opzetten (o.v.t.) voor de hosting van onze applicaties. Die tijd ligt inmiddels lang achter ons (voor mij persoonlijk een gemis , maar een uitstekende stap voorwaarts voor het bedrijf). Is die support er inmiddels?

[Dutchtraveller]

Werk al 25 jaar met Solaris systemen...
Voor de meeste databases moet je de blocksize van het ZFS volume aanpassen van 4k naar 8k omdat dat de pagesize is waar de db mee werkt. Dat staat los van de onderliggende storage (zpool).
Direct I/O heb ik nog nooit nodig gehad. Ik zag dat er wel een patch is geweest om dat toe te voegen maar in de versie die ik thuis draai zie ik nog geen support.

[damouze]

Direct I/O support is vrij gangbaar in de database wereld. Sybase ASE leunt er bijvoorbeeld op.

[- peter -]

Heb al jaren een Ubuntu server met ZFS. 3x12TB tegenwoordig, maar de set begon met 3x3TB, toen 3x6TB en nu dus 3x12TB. Fijn om al je lokale backups op te hebben, en compressie helpt ook om t wat efficiënter te houden.

[Stetsed]

Top bestandssysteem kan er niet voor een betere vragen. Draai op laptop en desktop linux en daar heb ik het recent opgezet en het draait moeiteloos en met geen problemen, en de backups die alleen ruimte in nemen als er iets verandert is ook helemaal top. Ook op de server draai ik het en de RAM cache is zeer handig met het verselle van de pure HDD array.

[Videopac]

Hier ook goede ervaringen (Truenas/Asustor AS6704T).

[Dim]

Ik zou nog even watchen op 2.1.11, aangezien https://github.com/openzfs/zfs/issues/14753 nog openstaat. Dit kan in sommige gevallen voor data corruptie zorgen.

[jesperbelt]

One love, one filesystem.