Ask HN: Why not AI assisted ZFS rewrite?
Just thinking out loud..
If folks are doing a clean room rewrite of Adobe {Photoshop, et al}, MS Office, Fusion CAD etc, why don’t someone who works on filesystems do a clean room rewrite of ZFS and upstream it to the Linux kernel? BcacheFS was exciting until the core dev fought his way out of the Linux kernel. ZFS works great but has no legal pathway into the Linux kernel. But, Now that LLMs can largely write code faster under the watchful guidance of experienced engineers who knows what to do, why not wield that power to create something that is like ZFS but not encumbered by Oracle and have it part of Linux kernel?
I know the usual caveats about file systems, needing to be mature, battle tested and that vibe coding file systems is not the greatest of ideas.. if _I_ were to unilaterally vibe code a ZFS with LLMs and tell folks to use it, it will be colossally stupid. I mean it as a wide open source project with participation from the right people with an open mind.
The problem isn't the code. I could "just" cp -r openZFS into Linux/fs/zfs or whatever. The problem is the copyright owner is going to sue you, and I ain't got time for that headache, nor the money for the lawyer to defend that lawsuit. Which I'd probably lose. Laundering it through AI isn't enough to fend off that lawsuit.
bcachefs exists outside of any drama. I switched my pools to it from ZFS last year and it is working swimmingly. What ZFS use case do you have that bcachefs does not solve? Only thing I can think of is zfs send/receive and I never used that.
Both bcachefs and ZFS are social problems, not technical. Nothing stops a distro from shipping ZFS as part of their kernel. Except a legal interpretation of whether CDDL and GPL2.0 allow that marriage.
I think bcachefs social problems come in part from its hidden technical deficits. “FS implemented as A DB” is a big, leaky idea which undermines userspace claims like “Filesystem code doesn't know about locking or journalling”. Restart-safety being required everywhere is quite a tax.
That leakiness becomes drama when it’s not acknowledged; the energy gets converted to last-minute bugfixes or convoluted workarounds. I’d argue separately that totalization (more than just btrees) threatens a software’s role, and that motivated role confusion forced bcachefs removal from the kernel.
Indeed they're non-technical problems, but really blocking ones. As a user, I dont want to have my filesystem and Kernel have a possibility of going out of sync leading to an unusable system during a regular update.
The biggest attractor towards BcacheFS for me was the possibility of that cohesion. All the technical merits were a bonus as ZFS does already what I wish for. That factor went away with BcacheFS choosing to not get mainlined into Linux Kernel. Now we have two good filesystems outside the kernel :-(