bcachefs is probably the other big name here, but since distros still seem to pick btrfs, I don't think it's considered "production ready" yet. The bcachefs website still labels it as "beta" quality.
bcachefs is written by the same person who wrote bcache... And that has a lot of subtle eat-your-data pitfalls.[1] I don't really trust bcachefs not to do the same.
But... any of the other stuff? Checksums, deduplication, compression, etc. Citations, please.
LVM VDO wasn't really a thing until a couple of years ago, and I've never actually heard anyone recommend using it. Definitely not within its "traditional domain".
Perhaps you mean on other operating systems... when this discussion is all about a Linux filesystem and whether other Linux filesystems provided these features, including the comment you replied to?
> But... any of the other stuff? Checksums, deduplication, compression, etc. Citations, please.
Yes. The Linux LVM logical volume manager for example can do those things.
Traditional domain meaning this kind of data management traditionally came under the purview of LVMs. Not that an implementation has had particular features for a length of time, but that you might (also) look there rather than the filesystem for those features.
Deduplication and compression have traditionally been file system features not volume management features:
As fair as I know the only solution for deduplication in LVM is VDO and that was created after ZFS and isn't technically part of LVM (it's a kernel module that sits between the filesystem and LVM).
Same is true for compression except in the case of compression that's been a file system feature since the days of NTFS on NT 3.5 (released 1995) -- I can't recall when UNIX file systems first saw compression but I'd wager it was before ZFS, which we've already acknowledge predates VDO.
I also thing it makes sense that the above should be part of the file system domain because it's an integral part to how the file system organizes the data (much like how we don't argue that the journal isn't part of the file system domain).
As for checksums, they have existed in all parts of the stack, from the application level (for example rsync), to the volume level (RAID controller cards) to the file system. I wouldn't say that's something that has ever had a "traditional domain".
The things I'd say ZFS and its ilk do that isn't part of its traditional domain is RAIDing (ie management of the physical devices) and cache control. Both make a lot of sense being managed by the file system in modern file systems but I can also sympathize with those who think that's a step too far. In the case of RAIDing, you can still run ZFS on LVM or a hardware controller if you wish -- I wouldn't suggest you do so because it gives you additional complications for zero benefit but the option is still there if you want it. But with regards to cache, the only way to opt out of ZFS managing it's own cache is not to use ZFS.
Data plane management sure has traditionally been done with logical volume managers on unix particularly which introduced logical volume managers around late 80s. Not sure when deduplication exactly was available for Linux, probably around the same time as it was for ZFS on Solaris with VxVM. Various other vendors had their own LVM based dedup (NetApp comes to mind).
Anyway it wasn't really a statement about what was there first or not, but rather that because something may not exist for a filesystem does not mean it does not exist, i.e., look at other layers for such functionality.
Are they going to add zfs to the TUI installer for Ubuntu Server? I've tried several times over the last year, and I have yet to find a good method for getting Ubuntu Server running on zfs root.
Step 1 ("Prepare the Install Environment") starts by assuming you have a Live CD, which implies the desktop distro. I've been to that guide several times while searching fruitlessly for a method to install Ubuntu server onto a zfs root. I think you would basically have to spin your own ISO at this point.
Does any other FS on Linux provide those?