Rob 💚

Four years in the making... 🫠 https://github.com/openzfs/zfs/pull/19129 #OpenZFS

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/

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! https://github.com/openzfs/zfs/tree/master/tests/unit 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 project for me for years, 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!

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

@Tubsta@soc.feditime.com yes, no change to what we actually support, just a change to how we (try to) communicate it. This is actually better compared to what we had before. Before we said "4.18" because that's the number RHEL8 declared, but in reality it has lots of features from kernels much newer than that. Meanwhile, _actual_ 4.18 was EOL years ago and uncompilable these days. It's harder to communicate than a version range, but its also not a meaningless statement like a straight version range was! More here: https://github.com/openzfs/zfs/pull/18295

@Tubsta@soc.feditime.com heh yeah, right as we were merging this. I'll get it updated soon. still, the description remains: anything still in support

@mattcen@aus.social 🎶 funny shops with funny names 🎶

@pesco@bsd.network yeah, agreed. this one was easy because its all summary of other things out there; if you didn't like it, you can just go find the source material yourself. I've been thinking about other shapes this might take. I've wanted to do a ZFS newsletter for a while, and I think this method could be useful, but for something that is a bit more curated and editorial, and being delivered via email, I think the bar is higher, but I still think it might be useful to get the first draft up and running

@hyc@mastodon.social "I don't see any bears around here" doesn't mean "bears do not exist". I personally know community managers and technical writers who care deeply about their particular open source projects, so at least, I know that some exist somewhere. I also know they would like to do more, or have had to do less, because they need to spend their time on things that bring in money. I also know that we traditionally don't place much value on these roles, so it wouldn't surprise me to find tech writers out there who would like to contribute more, but then balk at the amount of their own time and energy they're going to have to sink into it, and go do something else. Also, "tech writers who want to contribute to open source" is a narrow field to select from. If there's money on the table, we've now widened it to "tech writers who want to be paid". I can definitely find more of those. It sounds like you might actually be in a good position! You say _almost_ never, so you do sometimes get doc contributions? Are they good? Have you asked those people why they don't contribute more? Have you offered to pay them to do more? On the other side, what kind of user requests do you get about your documentation? Is there stuff out-of-date, missing, confusing, etc? Enough to pull together a list of things you'd like to pay someone to do? Because if you've got money and a job description, you're already most of the way to finding someone to do it!

@hyc@mastodon.social if you only want people that are already using software and have time to contribute to it, that's totally ok. I got no problem with that, it works for a lot of projects and has for a long time. all I'm pushing back on is idea that no one showing up means that no one exists. it _might_ mean that, but it might also be a discovery problem (do they know you exist), or might be that your terms (prior interest or use case) don't align with what that person wants to achieve, or wants in exchange.

@lyrial@transfem.social I've no idea where it comes from tbh.