incredibly nice

Posted Nov 7, 2025 0:24 UTC (Fri) by muase (subscriber, #178466)
In reply to: incredibly nice by josh
Parent article: Toward fast, containerized, user-space filesystems

Which would be a useful argument, if Linux had an alternative that would fill that niche. Don't get me wrong – I'm not blaming Linux for the license problematic; that's definitely Sun's fault (but: also not the fault of the OpenZFS developers).

> This is a problem on the ZFS end, originating from its original release and license, not a problem on the Linux end

But I disagree on this stance, It is a huge problem on the Linux end too, because up until today there is literally no first-class filesystem that combines modern features in a stable way. Cow, snapshots, online-dedup, encryption, compression, datasets, raid-likes, ... – all those are useful features for a variety of systems; and something where Linux is decades behind by now.

And I think a hostile stance is an understandable interpretation here. ZFS in the kernel wouldn't work; that's clear – but there are a lot of possible compromises. You could give (unofficial) API guarantees, you could do cooperative development, or maybe at least coordinate breaking changes to affected APIs etc. – I mean, we have shims for closed-source GPU drivers nowadays; but friendly cooperation from one open-source-community to another to maybe not unnecessarily break a DKMS module is impossible now?

Let's be real – the ZFS-on-Linux problems are not due to license mismatch; they're because some parts have zero interest in any form of even soft-cooperation here. And that's fair – but IMO it's also fair to call that out.

incredibly nice

Posted Nov 7, 2025 0:46 UTC (Fri) by josh (subscriber, #17465) [Link] (2 responses)

I don't think it's reasonable to characterize the response as "hostile" in the first place. ZFS is incompatible with the Linux kernel. Anything derived from it will never be in the Linux kernel.

If someone wanted to write a clean-room implementation, that'd be awesome. But in the meantime, the list of features ZFS has is entirely immaterial to the question of "cooperation". ZFS can't ever be in the Linux kernel until someone writes a clean-room implementation under a compatible license.

Meanwhile, even *nvidia* of all people has managed to transition away from proprietary kernel drivers.

> You could give (unofficial) API guarantees, you could do cooperative development, or maybe at least coordinate breaking changes to affected APIs etc

https://docs.kernel.org/process/stable-api-nonsense.html

incredibly nice

Posted Nov 7, 2025 2:43 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link]

The kernel - Christoph, really - are pretty hostile to out of tree code.

He wasted no time with yanking an EXPORT_SYMBOL() on code I originally authored, and nacks patches over EXPORT_SYMBOL() vs. EXPORT_SYMBOL_GPL()...

I totally get being hostile to the likes of VMWare, but ZFS? Really?

incredibly nice

Posted Nov 7, 2025 5:33 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

> But in the meantime, the list of features ZFS has is entirely immaterial to the question of "cooperation".

Why?

> ZFS can't ever be in the Linux kernel until someone writes a clean-room implementation under a compatible license.

The comment you're replying to already explains that "cooperation" does not entail putting ZFS "in the Linux kernel," so this is a non sequitur.