Anyway I just finished the (preliminary) #OpenZFS support patches for #Linux 7.4. I'll just hold on to it until at least 7.3 appears 🤷

Four years in the making... 🫠

https://github.com/openzfs/zfs/pull/19129

#OpenZFS

OK so I'm at a bit of a loss for what to put up for #EverythingOpen next year, so I'm now taking ideas and requests!

My personal constraints for talks are: enough content to fill 45mins, works best in a presentation setting, and gives the audience something they couldn't have got elsewhere. Basically: this couldn't have been an email.

I could do something about #OpenZFS specifically, or filesystems in general, but I wanna know what you want to hear about. I have the bones of a "myths programmers believe" -style talk, but I'm not sure it has a point beyond "files are weird, man". And filesystem dev chat is not usually of much interest to a general audience, which is what this conference is.

Open source culture stuff has been my more recent special interest. Last year I did freelancing and funding and don't have much more to say there. I think I have in me somewhere a talk that covers long term maintenance, governance, values, AI, moving slowly, confidence in our craft and our communities, kindness and optimism. I don't know what it is yet though, which at least means it's gonna be a lot of work, and might just mean me pointing at things and saying "nice!" or "oh no" with few answers (see last year's talk, or most recent blog post, to get a sense of my non-committal style). That's OK if people want it, but still.

Anyway let me know, no matter how silly. Ten silly ideas, four minutes each, might work if I can find a vaguely plausible through-line!

💚

I've spent the year listening to and thinking about the AI discourse and have concluded that we have had enough AI discourse and should not have any more of it.

https://despairlabs.com/blog/posts/2026-09-03-stop-obsessing-about-the-robot/

Yesterday, just for fun, I started porting to #OpenZFS to #HaikuOS.

The userspace kernel is running nicely. Here's ztest, the stress/fuzz tool, ticking along, doing what it does. zdb is live too, and the unit tests pass. Not bad for two afternoons!

Don't be fooled, this is not very far along. The userspace kernel is mostly test tools running over the ZFS core, and doesn't really require much beyond POSIX basics. Still, building and running is a good place to start!

Also don't get too excited; this was an excuse to look at Haiku again after their recent release, and a bit of decompressing after an intense couple of weeks. I'm going on vacation next week, and then back to my regularly scheduled work.

That said, I will keep poking at this. One of my long term projects is making OpenZFS easier to port or integrate with other systems, which is most a lot of slow, careful refactoring. Actually building a platform interface from scratch is a pretty good way to find out where some of the more awkward seams are.

RE: https://mastodon.social/@openzfs/117167091602143866

It has been a very long couple of weeks.

Do you use #OpenZFS? Do you ship a product or service with #ZFS in it? Do you work on a storage- or filesystem-related project and are interested in how ZFS could make it better? Are you interested in the future of software-defined storage?

If any of these are you, you should consider presenting at the OpenZFS User and Developer Summit 2026! Our CfP is open until September 11, and we'd love to hear from you!

https://openzfs.org/wiki/OpenZFS_User_and_Developer_Summit_2026

#Linux #FreeBSD #illumos #NAS #homelab

Start your weekend with a new #OpenZFS release!

2.4.4 and 2.3.9 are the new Stable and LTS releases. Loads of interesting bugfixes, and support for Linux 7.2.0. Meanwhile, 2.2.11 gets a small number of the most important fixes.

Get them via the links below, or look for them in OS repositories in the next few days. Thanks to everyone who contributed!

https://github.com/openzfs/zfs/releases/tag/zfs-2.4.4
https://github.com/openzfs/zfs/releases/tag/zfs-2.3.9
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.11

#ZFS #Linux #Debian #Ubuntu #Fedora #FreeBSD

We are pleased to announce the 2026 #OpenZFS User and Developer Summit in Portland, Oregon, October 27th through 30th.

Watch for the Call for Participation and Registration!

https://openzfs.org/wiki/OpenZFS_Developer_Summit_2026

I rewrote the whole snapmount facility in #OpenZFS (Linux port).

It's .. pretty full on.

https://github.com/openzfs/zfs/pull/18847

Here's my talk from #EO2026, "the unreasonable cost of open source contribution".

We all say we want lots of high quality open source software, but we don't like to pay for it. When we do talk about it, we rarely talk about the actual human on the end of it doing the work, and their wants, and needs, and aspirations and capabilities. We make the people invisible, and so we don't notice when they're burning out, or when they just disappear.

I can only tell you about one such person - me. So this talk is where I tell you about who I am, what I do, who I do it for, and how much that actually costs in real dollar terms, and I encourage you to think hard about your version of this talk. If we're serious about the open source future we say we want, then we have to talk about the humans that will do that work, or we all lose.

https://www.youtube.com/watch?v=9_HLxReyFq0

Earlier this year I told a story in a conference talk. This is the behind-the-scenes story of that story. Weirdly, they're both basically the same story.

https://despairlabs.com/blog/posts/2026-07-05-conference-presentation-cost/

Update: there was a little background kerfuffle after my post, and the video landed a few hours later.

The point - "be honest with your speakers" - has not changed.

https://social.lol/@robn/116870902050085793

New #OpenZFS releases today!

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.10

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 zpool and zfs commands, 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 normalization and casesensitivity properties, which control how filenames are compared and matched. We have some ancient tests in ZTS (the casenorm group) 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!

openzfs/tests/unit/README

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. namecheck is 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!

Ever wondered how the #OpenZFS readonly filesystem property interacts with the ro and rw mount options, and if using mount(8) vs zfs-mount(8) changes anything, and if your choice of platform changes anything?

I certainly hadn't, until I got a bug report that I'd subtly changed a couple of cases in 2.4.2 for Linux. I unbroke it, but not before spending a bunch of time trying to figure out what "unbroke" means. Emphasis on "trying".

Here's the fix, with my endless 🤔 in the collapsed "bonus" section. Good speluncking opportunity available if you'd like to figure it out!

https://github.com/openzfs/zfs/pull/18563

#OpenZFS 2.4.2 and 2.3.7 are here. Includes support for #Linux 7.0 and a big pile of fixes. Available now from all good software retailers!

https://github.com/openzfs/zfs/releases/tag/zfs-2.4.2

https://github.com/openzfs/zfs/releases/tag/zfs-2.3.7

Tick tock, it's #OpenZFS on #Linux 7.1 o'clock.

https://github.com/openzfs/zfs/pull/18471

Needed a palate cleanser this week, so dusted off and pushed on some old experiments and made this tiny toy #OpenZFS dashboard. This is all it is, just displaying live pool traffic, but it was nice and fun to make!

RE: https://oldbytes.space/@jonyesno/116366110590403972

Meet my good friend @jonyesno He's everything you’d want from the modern #sysadmin - seen everything from old mainframes to modern cloud infrastructure and every weird thing in between, and has a record of quickly coming up to speed and getting stuff done no matter what size or shape of computer or service you’ve got there.

It’s a tricky time for IT organisations: everything is expensive and in short supply, so we’re all looking for ways to keep the hardware and software we already have running well. Hiring someone like Jon is an easy way to stretch your sysadmin budget - you’ll get careful and thoughtful service, great ideas you hadn’t thought of, and a genuinely kind and caring attitude.

Bonus: a steady stream of space, train, cat, old computer and good drink content. You see why I keep him around. Give him a call!

#linux #freebsd #illumos #solaris #zfs

#OpenZFS now has much more detailed information about which varieties of Linux are supported.

tl;dr: all kernel.org "longterm" series, all RHEL active & maintenance series (including clones), and Ubuntu LTS.

(No actual change in practice, just trying to write it down a bit more clearly).

https://github.com/openzfs/zfs/?tab=readme-ov-file#supported-kernels-and-distributions