#openzfs — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #openzfs, aggregated by home.social.
-
@pertho Some years back we (my work) licensed SPECsfs2014, the SPEC consortium's file-system benchmark. We still weren't able to get much out of it, because the SPEC workload models weren't very realistic, or at least didn't relate usefully to our users' workloads. I've discussed at a couple of #OpenZFS user summits the need for both better workload models and a mechanism to *build* models from real-life workloads rather than armchair theorizing.
-
@pertho Some years back we (my work) licensed SPECsfs2014, the SPEC consortium's file-system benchmark. We still weren't able to get much out of it, because the SPEC workload models weren't very realistic, or at least didn't relate usefully to our users' workloads. I've discussed at a couple of #OpenZFS user summits the need for both better workload models and a mechanism to *build* models from real-life workloads rather than armchair theorizing.
-
We had THE TALK on the #OpenZFS production user call regarding pragmatic encrypted dataset management.
-
We had THE TALK on the #OpenZFS production user call regarding pragmatic encrypted dataset management.
-
The recording of the July 8th, 2026 #OpenZFS Production User Call is up:
We discussed Rob Norris' recent commits and active projects, OpenZFS security handling, the "mountpoint" property, a long-overdue deep dive into practical encrypted dataset management, desired encryption features, and more!
"Don't forget to slam those Like and Subscribe buttons."
You can support all Call For Testing efforts via BSD Fund: https://bsdfund.org
-
The recording of the July 8th, 2026 #OpenZFS Production User Call is up:
We discussed Rob Norris' recent commits and active projects, OpenZFS security handling, the "mountpoint" property, a long-overdue deep dive into practical encrypted dataset management, desired encryption features, and more!
"Don't forget to slam those Like and Subscribe buttons."
You can support all Call For Testing efforts via BSD Fund: https://bsdfund.org
-
🤔🤪 "How to Build a Minimal #ZFS #NAS Without Synology, QNAP, TrueNAS" is the epic saga of someone who thinks slapping together some random hardware and sprinkling in "OpenZFS" is the ultimate life hack. 🛠️😅 Because, clearly, the world needed another guide on how to be a tech hipster by not using the perfectly good tools that already exist. 🤷♂️
https://neil.computer/notes/how-to-setup-minimal-zfs-nas-without-truenas/ #OpenZFS #TechHacks #DIYStorage #Minimalism #HackerNews #ngated -
🤔🤪 "How to Build a Minimal #ZFS #NAS Without Synology, QNAP, TrueNAS" is the epic saga of someone who thinks slapping together some random hardware and sprinkling in "OpenZFS" is the ultimate life hack. 🛠️😅 Because, clearly, the world needed another guide on how to be a tech hipster by not using the perfectly good tools that already exist. 🤷♂️
https://neil.computer/notes/how-to-setup-minimal-zfs-nas-without-truenas/ #OpenZFS #TechHacks #DIYStorage #Minimalism #HackerNews #ngated -
I am experiencing this with #OpenZFS
➜ ~ sudo zpool status -x
pool: ughetto
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
scan: scrub in progress since Sat Jun 27 18:44:31 2026
141G / 141G scanned, 11.8G / 141G issued at 184M/s
0B repaired, 8.39% done, 00:12:00 to go
config:
NAME STATE READ WRITE CKSUM
ughetto DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
653332104939013944 UNAVAIL 0 0 0 was /dev/sdb1
sdc ONLINE 0 0 0
cache
sda FAULTED 0 0 0 corrupted data
errors: No known data errorsThis has already happened, but at a point where I didn’t mind losing the data, so I destroyed the pool and I recreated it from scratch, with no errors. Now, I would like to try to repair the corrupted data… Any tips? I would hate it if I have to throw away the hard disk, it’s less than one year old and I have been using it only for a couple of months… Is replacing the disk my only option?
#ZFS #systemAdministration #help #sysAd #techSupport #dataLoss #storage #partition #hardDisk #HDD #Linux #filesystem #data #storage
-
I am experiencing this with #OpenZFS
➜ ~ sudo zpool status -x
pool: ughetto
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
scan: scrub in progress since Sat Jun 27 18:44:31 2026
141G / 141G scanned, 11.8G / 141G issued at 184M/s
0B repaired, 8.39% done, 00:12:00 to go
config:
NAME STATE READ WRITE CKSUM
ughetto DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
653332104939013944 UNAVAIL 0 0 0 was /dev/sdb1
sdc ONLINE 0 0 0
cache
sda FAULTED 0 0 0 corrupted data
errors: No known data errorsThis has already happened, but at a point where I didn’t mind losing the data, so I destroyed the pool and I recreated it from scratch, with no errors. Now, I would like to try to repair the corrupted data… Any tips? I would hate it if I have to throw away the hard disk, it’s less than one year old and I have been using it only for a couple of months… Is replacing the disk my only option?
#ZFS #systemAdministration #help #sysAd #techSupport #dataLoss #storage #partition #hardDisk #HDD #Linux #filesystem #data #storage
-
reboot -r
– no longer reboots the operating system. Not reproducible with FreeBSD 15.1-RELEASE.
In the ALT text here (auto-detected):
Trying to mount root from zfs:maximal/ROOT/sixteen []...
FreeBSD 16.0-CURRENT main-n286985-90ea8e89d9b7 GENERIC-NODEBUG amd64 1600019 1600019
<https://cgit.freebsd.org/src/log/?qt=range&q=90ea8e89d9b7&h=main>, I have not attempted to bisect.
Seeking RB_REROOT in GitHub finds two commits, the most recent (December 2025):
<https://github.com/freebsd/freebsd-src/commit/4453ec5b8716bc465ff5192986099dc75d1f2ce7>
– is that the regression, or am I way off? According to cgit, it has not been cherry-picked to releng/15.1 <https://cgit.freebsd.org/src/log/?qt=grep&q=reboot%3A+Default+to+a+clean+shutdown&h=releng%2F15.1> or stable/15.
-
reboot -r
– no longer reboots the operating system. Not reproducible with FreeBSD 15.1-RELEASE.
In the ALT text here (auto-detected):
Trying to mount root from zfs:maximal/ROOT/sixteen []...
FreeBSD 16.0-CURRENT main-n286985-90ea8e89d9b7 GENERIC-NODEBUG amd64 1600019 1600019
<https://cgit.freebsd.org/src/log/?qt=range&q=90ea8e89d9b7&h=main>, I have not attempted to bisect.
Seeking RB_REROOT in GitHub finds two commits, the most recent (December 2025):
<https://github.com/freebsd/freebsd-src/commit/4453ec5b8716bc465ff5192986099dc75d1f2ce7>
– is that the regression, or am I way off? According to cgit, it has not been cherry-picked to releng/15.1 <https://cgit.freebsd.org/src/log/?qt=grep&q=reboot%3A+Default+to+a+clean+shutdown&h=releng%2F15.1> or stable/15.
-
Manipulating a Pool from the Rescue System - Klara Systems
https://klarasystems.com/articles/manipulating-a-pool-from-the-rescue-system/
-
Manipulating a Pool from the Rescue System - Klara Systems
https://klarasystems.com/articles/manipulating-a-pool-from-the-rescue-system/
-
@oxy I enjoyed a killing on Kubuntu 26.04 a day or so ago.
IIRC free memory and swap were nearly exhausted (unrelated to ARC) due to VirtualBox throwing a wobbly with a FreeBSD guest, following a disrupted connection to an old mobile hard disk drive on USB, which I use (with OpenZFS) to store the virtual hard disks for many of my test machines.
I feared that Firefox would be killed.
Happily: Linux made VirtualBox, which was not responding, the victim.
-
@oxy I enjoyed a killing on Kubuntu 26.04 a day or so ago.
IIRC free memory and swap were nearly exhausted (unrelated to ARC) due to VirtualBox throwing a wobbly with a FreeBSD guest, following a disrupted connection to an old mobile hard disk drive on USB, which I use (with OpenZFS) to store the virtual hard disks for many of my test machines.
I feared that Firefox would be killed.
Happily: Linux made VirtualBox, which was not responding, the victim.
-
#OpenZFS challenge of the, erm, summer, I guess. Several of my NFS servers were built using gmultipath(4) and I want them to stop (it's bad for performance and doesn't benefit reliability). I've already fixed the cabling so the HBA knows it has 8 lanes to each enclosure. Now I have to zpool detach, gmultipath destroy, and zpool attach each drive to get gmultipath out of the way, waiting for a resilver each time, for each drive in about 100 mirror pairs across five servers.
-
#OpenZFS challenge of the, erm, summer, I guess. Several of my NFS servers were built using gmultipath(4) and I want them to stop (it's bad for performance and doesn't benefit reliability). I've already fixed the cabling so the HBA knows it has 8 lanes to each enclosure. Now I have to zpool detach, gmultipath destroy, and zpool attach each drive to get gmultipath out of the way, waiting for a resilver each time, for each drive in about 100 mirror pairs across five servers.
-
New 𝗘𝘅𝗽𝗮𝗻𝗱 𝗚𝗘𝗟𝗜 𝗘𝗻𝗰𝗿𝘆𝗽𝘁𝗲𝗱 𝗕𝗵𝘆𝘃𝗲 𝗩𝗠 𝗭𝗙𝗦 𝗗𝗶𝘀𝗸 [Expand GELI Encrypted Bhyve VM ZFS Disk] article on vermaden.wordpress.com.
https://vermaden.wordpress.com/2026/06/17/expand-geli-encrypted-bhyve-vm-zfs-disk/
-
New 𝗘𝘅𝗽𝗮𝗻𝗱 𝗚𝗘𝗟𝗜 𝗘𝗻𝗰𝗿𝘆𝗽𝘁𝗲𝗱 𝗕𝗵𝘆𝘃𝗲 𝗩𝗠 𝗭𝗙𝗦 𝗗𝗶𝘀𝗸 [Expand GELI Encrypted Bhyve VM ZFS Disk] article on vermaden.wordpress.com.
https://vermaden.wordpress.com/2026/06/17/expand-geli-encrypted-bhyve-vm-zfs-disk/
-
We are pleased to announce #OpenZFS releases 2.4.3, 2.3.8 and 2.2.10:
https://github.com/openzfs/zfs/releases/tag/zfs-2.4.3
https://github.com/openzfs/zfs/releases/tag/zfs-2.3.8
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.10Thank you everyone who helped make these possible!
-
We are pleased to announce #OpenZFS releases 2.4.3, 2.3.8 and 2.2.10:
https://github.com/openzfs/zfs/releases/tag/zfs-2.4.3
https://github.com/openzfs/zfs/releases/tag/zfs-2.3.8
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.10Thank you everyone who helped make these possible!
-
#ProxmoxMailGateway 9.1 has been released ( #Proxmox / #ProxmoxMG / #MailGateway / #ZFS / #OpenZFS / #SpamAssassin / #Postfix / #PostgreSQL / #Linux / #Debian / #Trixie / #DebianTrixie ) https://proxmox.com/
-
#ProxmoxMailGateway 9.1 has been released ( #Proxmox / #ProxmoxMG / #MailGateway / #ZFS / #OpenZFS / #SpamAssassin / #Postfix / #PostgreSQL / #Linux / #Debian / #Trixie / #DebianTrixie ) https://proxmox.com/
-
Introducing #OpenZFS Unit Tests:
-
Introducing #OpenZFS Unit Tests:
-
In the last few weeks #OpenZFS has grown a unit test framework!
This is different to the existing "ZTS" integration/functional test suite. That's running the
zpoolandzfscommands, creating and destroying pools, writing to files, and all sorts of "user-facing" stuff to confirm operation.This is more like what you'd expect - targeting specific internal functions and APIs, mocking objects and behaviours that sit "under" those, to confirm that they do what they should.
Unit testing in C, especially very old C software, is traditionally quite complicated, and it will be for some of the very complicated and entangled parts of OpenZFS, but there's a huge amount of code that is behind pretty mundane and boring and narrow APIs that are easy to test.
A few months ago I was looking into the very old
normalizationandcasesensitivityproperties, which control how filenames are compared and matched. We have some ancient tests in ZTS (thecasenormgroup) that have never passed cleanly, and have long been on the ignore list (see #7633). I started looking into them, and followed path into the ZAP subsystem, which is our on-disk K/V data structure that we use for tons of stuff - filesystem directories are the thing you see, but internally, dataset and pool property lists, dedup and clone tables, and tons of other metadata. Its a critical component, and also very old, very quirky, and very hard to understand.I've long wanted to do experiments with different kinds of on-disk K/V formats, but haven't because messing in there is intimidating and the potential blast radius is extreme. For the same reason, I haven't spent much time looking at adding ZAP "housekeeping" operations, like defragement, rebalance, etc. Now I was faced with the same issue again, this time to try to understand and possibly fix a bug in the name lookup machinery.
ZTS tests OpenZFS from "outside". It makes sure directories work, for example, but it mostly can't tell what's happening under the hood. There are some things that can be inferred, eg by checking counters and metrics, looking for evidence that certain things have happened. That's good for confirming that you haven't broken an existing mechanism, but doesn't help if your whole purpose is to change the existing mechanism.
Of course, I've long known that unit tests were what I wanted here, but we didn't really have that in any general way (there are a small handful of unit-test-like drivers in ZTS, but they're ad-hoc and don't really fit inside an integration test suite). So I finally took the hit and got on with it, making a unit test framework as small and focused as I possibly could, that was quick and easy to run and easy to iterate on and just pleasant to use! I made a particular effort to show a short and sharp coverage summary right there in the output. I even wrote some docs!
While building the framework, I started writing the ZAP tests alongside it. Those are making tremendous progress.What you see in the above link and the images below is where we're at today. I've still got another set to land which tests some of the existing internal housekeeping functions, but more important than that, I already have good progress on a substantial refactor, trying to clear out some of the quirks and modernise the structure. Very nice with a safety net underneath.
Even more exciting to me though, is that it hasn't taken long for another contributor to start building out test suites for other areas of the codebase.
namecheckis the set of functions used to validate names of things - pool, dataset, mountpoint, etc. Important, low hanging fruit, easy to write a test case for. And got to 100% coverage before I did, boooo but yaaay!Anyway, I'm pretty excited about this. Making OpenZFS easy for new developers to immediately start doing useful work has been a long-term goal for me for years (see also quiz), and this is just another thing that will definitely make my life easier and hopefully a bit easier for others too! If nothing else, there's lots of tests to be written!
-
In the last few weeks #OpenZFS has grown a unit test framework!
This is different to the existing "ZTS" integration/functional test suite. That's running the
zpoolandzfscommands, creating and destroying pools, writing to files, and all sorts of "user-facing" stuff to confirm operation.This is more like what you'd expect - targeting specific internal functions and APIs, mocking objects and behaviours that sit "under" those, to confirm that they do what they should.
Unit testing in C, especially very old C software, is traditionally quite complicated, and it will be for some of the very complicated and entangled parts of OpenZFS, but there's a huge amount of code that is behind pretty mundane and boring and narrow APIs that are easy to test.
A few months ago I was looking into the very old
normalizationandcasesensitivityproperties, which control how filenames are compared and matched. We have some ancient tests in ZTS (thecasenormgroup) that have never passed cleanly, and have long been on the ignore list (see #7633). I started looking into them, and followed path into the ZAP subsystem, which is our on-disk K/V data structure that we use for tons of stuff - filesystem directories are the thing you see, but internally, dataset and pool property lists, dedup and clone tables, and tons of other metadata. Its a critical component, and also very old, very quirky, and very hard to understand.I've long wanted to do experiments with different kinds of on-disk K/V formats, but haven't because messing in there is intimidating and the potential blast radius is extreme. For the same reason, I haven't spent much time looking at adding ZAP "housekeeping" operations, like defragement, rebalance, etc. Now I was faced with the same issue again, this time to try to understand and possibly fix a bug in the name lookup machinery.
ZTS tests OpenZFS from "outside". It makes sure directories work, for example, but it mostly can't tell what's happening under the hood. There are some things that can be inferred, eg by checking counters and metrics, looking for evidence that certain things have happened. That's good for confirming that you haven't broken an existing mechanism, but doesn't help if your whole purpose is to change the existing mechanism.
Of course, I've long known that unit tests were what I wanted here, but we didn't really have that in any general way (there are a small handful of unit-test-like drivers in ZTS, but they're ad-hoc and don't really fit inside an integration test suite). So I finally took the hit and got on with it, making a unit test framework as small and focused as I possibly could, that was quick and easy to run and easy to iterate on and just pleasant to use! I made a particular effort to show a short and sharp coverage summary right there in the output. I even wrote some docs!
While building the framework, I started writing the ZAP tests alongside it. Those are making tremendous progress.What you see in the above link and the images below is where we're at today. I've still got another set to land which tests some of the existing internal housekeeping functions, but more important than that, I already have good progress on a substantial refactor, trying to clear out some of the quirks and modernise the structure. Very nice with a safety net underneath.
Even more exciting to me though, is that it hasn't taken long for another contributor to start building out test suites for other areas of the codebase.
namecheckis the set of functions used to validate names of things - pool, dataset, mountpoint, etc. Important, low hanging fruit, easy to write a test case for. And got to 100% coverage before I did, boooo but yaaay!Anyway, I'm pretty excited about this. Making OpenZFS easy for new developers to immediately start doing useful work has been a long-term goal for me for years (see also quiz), and this is just another thing that will definitely make my life easier and hopefully a bit easier for others too! If nothing else, there's lots of tests to be written!
-
@brettm thanks.
Logically: anyone who chooses to reject FreeBSD on that basis may also choose to reject all projects that use OpenZFS. I can not recommend such sweeping rejections.
Two of the three commits:
― range_tree: use zfs_panic_recover() for partial-overlap remove · openzfs/zfs@6495daf — <https://github.com/openzfs/zfs/commit/6495dafd58b94a44fc9bc966ef47d6bc6916f5b9> (2026-02-25)
― Fix read corruption after block clone after truncate · openzfs/zfs@1644e2f — <https://github.com/openzfs/zfs/commit/1644e2ffd2640fa3e2c191ceaf048a5fc8399493> (2026-04-14)
I don't foresee a fork of OpenZFS.
I'm a very happy user of OpenZFS-native encrypted root-on-ZFS with Ubuntu-based Kubuntu.
-
@brettm thanks.
Logically: anyone who chooses to reject FreeBSD on that basis may also choose to reject all projects that use OpenZFS. I can not recommend such sweeping rejections.
Two of the three commits:
― range_tree: use zfs_panic_recover() for partial-overlap remove · openzfs/zfs@6495daf — <https://github.com/openzfs/zfs/commit/6495dafd58b94a44fc9bc966ef47d6bc6916f5b9> (2026-02-25)
― Fix read corruption after block clone after truncate · openzfs/zfs@1644e2f — <https://github.com/openzfs/zfs/commit/1644e2ffd2640fa3e2c191ceaf048a5fc8399493> (2026-04-14)
I don't foresee a fork of OpenZFS.
I'm a very happy user of OpenZFS-native encrypted root-on-ZFS with Ubuntu-based Kubuntu.
-
FreeBSD bug 263171 – add loader(8) and boot loader menu support for boot with OpenZFS-encrypted ROOT
-
FreeBSD bug 263171 – add loader(8) and boot loader menu support for boot with OpenZFS-encrypted ROOT
-
One ZAP entry. One uint64_t in spa_t. One new CLI flag.
That's all it took to teach #OpenZFS to skip blocks the last scrub already verified.
`zpool scrub -C` ships in 2.4.0.
-
One ZAP entry. One uint64_t in spa_t. One new CLI flag.
That's all it took to teach #OpenZFS to skip blocks the last scrub already verified.
`zpool scrub -C` ships in 2.4.0.
-
#ProxmoxDatacenterManager 1.1 has been released ( #Proxmox / #ProxmoxDM / #ZFS / #OpenZFS / #Linux / #Debian / #Trixie / #DebianTrixie ) https://proxmox.com/
-
#ProxmoxDatacenterManager 1.1 has been released ( #Proxmox / #ProxmoxDM / #ZFS / #OpenZFS / #Linux / #Debian / #Trixie / #DebianTrixie ) https://proxmox.com/
-
#ProxmoxVE 9.2 has been released ( #Proxmox / #VirtualEnvironment / #Virtualization / #VirtualMachine / #VM / #Linux / #Debian / #Trixie / #DebianTrixie / #QEMU / #LXC / #KVM / #ZFS / #OpenZFS / #Ceph ) https://proxmox.com/
-
#ProxmoxVE 9.2 has been released ( #Proxmox / #VirtualEnvironment / #Virtualization / #VirtualMachine / #VM / #Linux / #Debian / #Trixie / #DebianTrixie / #QEMU / #LXC / #KVM / #ZFS / #OpenZFS / #Ceph ) https://proxmox.com/
-
The first beta release of TrueNAS 26, code named Halfmoon, is released with OpenZFS 2.4 and 10X performance gains.
Read what's new in TrueNAS 26-BETA1 here: https://ostechnix.com/truenas-26-beta-released/
#Truenas26 #Nas #Beta #Releases #Openzfs #NetworkAttachedStorage
-
The first beta release of TrueNAS 26, code named Halfmoon, is released with OpenZFS 2.4 and 10X performance gains.
Read what's new in TrueNAS 26-BETA1 here: https://ostechnix.com/truenas-26-beta-released/
#Truenas26 #Nas #Beta #Releases #Openzfs #NetworkAttachedStorage
-
The first beta release of TrueNAS 26, code named Halfmoon, is released with OpenZFS 2.4 and 10X performance gains.
Read what's new in TrueNAS 26-BETA1 here: https://ostechnix.com/truenas-26-beta-released/
#Truenas26 #Nas #Beta #Releases #Openzfs #NetworkAttachedStorage
-
The first beta release of TrueNAS 26, code named Halfmoon, is released with OpenZFS 2.4 and 10X performance gains.
Read what's new in TrueNAS 26-BETA1 here: https://ostechnix.com/truenas-26-beta-released/
#Truenas26 #Nas #Beta #Releases #Openzfs #NetworkAttachedStorage
