Caching, mostly. My desktop has two HDDs and one NVMe. The NVMe isn't nearly that fast -- it's a 970 Evo which tops out at 1.6 GB/s -- but it's still much faste

Caching, mostly. My desktop has two HDDs and one NVMe. The NVMe isn't nearly that fast -- it's a 970 Evo which tops out at 1.6 GB/s -- but it's still much faster than the HDDs. When I write data to the setup, bcachefs and ZFS had very different behaviour. ZFS: - Writes to the HDDs first. - Blocks further writes until the first ones are on disk, unless I use sync=disabled. (Which I do; it's safe for my use-case.) - Is in any case limited by how much can be buffered in RAM. - Doesn't write to the SSD (which is configured as cache) unless it first reads data into RAM and then that data gets dropped from the in-core ARC. BcacheFS: - Writes to the SSD first. - Writes to the HDDs at its leisure. - Can be told the NVMe is more reliable than the HDDs. - Can be configured to leave data uncompressed on the SSD (because even LZ4 is a notable drain at 1.6 GB/s), but use zstd for the HDDs (because it's async so why not, and decompressing zstd at 300 MB/s is no issue). - Uses LRU instead of ARC, so if your working set is larger than your cache ZFS will have much better behaviour... once it's warmed up. The bug I hit is apparently fixed now, so I'm likely to switch back to bcachefs more or less ASAP. My working set is not in fact smaller than my SSD... but I'll just get a second SSD, I think.