6 ms·

Because ZFS is not supported on OpenBSD. In fact he does mention in the beginning of the article that he was surprised that none of the NAS related file-system

Because ZFS is not supported on OpenBSD. In fact he does mention in the beginning of the article that he was surprised that none of the NAS related file-systems are not supported by OpenBSD. On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serve different use-cases.

swinglock 4y ago
Non ZFS filesystems are overly simplified, ignoring the problems they ought to be solving.
- arghwhat 4y ago
  ZFS is not the simplest solution to the problems that "ought to be solved", and the implementation can be rather annoying - lacking support for hardware configuration changes, using its own cache system sidestepping the one in the kernel, and generally not fitting in with normal filesystem paradigms. And that's not even addressing that incremental sends - a huge feature - was (is?) broken due to holebirth, making it unreliable. btrfs kinda blew up, but it would be nice to have a good and simple reliable filesystem that actually fits in with the others. ZFS is what we're stuck with till then.
  - swinglock 4y ago
    Some of them are grounded in Linux politics. I have hope in bcachefs but best not rush, we've all seen btrfs.
    - arghwhat 4y ago
      ZFS was never any prettier on BSD either, so wouldn't blame Linux in that. But yes, bcachefs is somewhat interesting. Or maybe btrfs manages to clean up their act one day.
      - fbhabbed 4y ago
        What's wrong with btrfs?
        asdf123a 4y ago
        as with all things GPL, victim of FUD campaigns by corporate america.
        arghwhat 4y ago
        excuse me what
        detaro 4y ago
        The parity-based RAID levels still are officially not safe for production, and overall many people don't quite trust it in more complex setups due to past bugs.
        doublepg23 4y ago
        Here’s an excellent run down that’s somewhat recent: https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/?amp=1 https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
        sillystuff 4y ago
        It depends on your use case. BTRFS still has deficiencies in how it does quotas (significantly slows down fs if you enable quotas). BTRFS raid 5 has a write hole like traditional raid 5. And, there is a problem that sometimes occurs with individual extents when you use dedup. One of the dedup tools predicts that the issue will occur and will skip dedupe on such extents. There were RFCs on proposals to address both the write hole and quota issues on LWN this year, with the write hole fix already having draft patches see "raid tree". BTRFS is fine if you are not doing things that can hit those edges.
      - blacklion 4y ago
        ZFS on FreeBSD was very pretty, till Linux guys added adb and other Linux-specific features.
  - masklinn 4y ago
    > ZFS is not the simplest solution to the problems that "ought to be solved" What are simpler solutions to the problems that ought to be solved?
    - arghwhat 4y ago
      A CoW filesystem itself is not much more complicated than a plain filesystem. Or maybe a CoW softraid, with the filesystem existing at a different layer. ZFS has countless bonus tunables, several types of caching distinct from the kernel VFS cache, its own write logs and special devices, multiple levels of topology (datasets in a pool consisting of vdevs consisting of drives), deduplication, compression, etc. It is also not at all user friendly. When set up right (and no changing your mind on setup), and when fed enough resources, it does it's job well, but simple or elegant cannot describe it.
      - klysm 4y ago
        I completely agree with that assessment. The core ideas behind how the CoW work are elegant, but the implementation is anything but elegant.
      - masklinn 4y ago
        You didn't answer the question. You can't claim that there are simpler solutions then not actually provide a simpler solution. Which handwaving is not. > A CoW filesystem itself is not much more complicated than a plain filesystem. And yet there isn't one out there, there's pretty much only ZFS and BTRFS, the latter having been in a state of almost-but-not-actually-working for over a decade now. bcachefs is the only contender and it remains a single-developer effort with little mainlining progress in the last few years.
        laumars 4y ago
        There’s also hammerfs. I’ve not used that though. I think the complaints levelled against ZFS is a little unfair though. I agree that there are more elegant ways to implement ZFS but actually what we have already works really damn well. And the comments about the CLI being hard to use is weird because having used a hell of a lot of different file systems over the years (including BtrFS), I’ve found ZFS to be remarkably easy. ZFS has saved me from a number of hardware failures. If it really were as bad as the comments on here have made out, it’s have lost data several times over.
nix23 4y ago
>On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serve different use-cases. Na...it's not overly complicated for what it is, but yes it is a behemoth. >that wants direct access to the block device. Yes for high-performance "enterprise"-setup's it is preferable, but absolutely not needed. > Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. That i think is the winning point here, just add bit-rot protection to ffs.
magicalhippo 4y ago
> that wants direct access to the block device You can set up a ZFS pool backed by files[1]. Probably not something you should do with data you really care about, but it's possible. [1]: https://linux.die.net/man/8/zpool https://linux.die.net/man/8/zpool (Virtual Devices)

swinglock 4y ago

Non ZFS filesystems are overly simplified, ignoring the problems they ought to be solving.

arghwhat 4y ago
ZFS is not the simplest solution to the problems that "ought to be solved", and the implementation can be rather annoying - lacking support for hardware configuration changes, using its own cache system sidestepping the one in the kernel, and generally not fitting in with normal filesystem paradigms. And that's not even addressing that incremental sends - a huge feature - was (is?) broken due to holebirth, making it unreliable. btrfs kinda blew up, but it would be nice to have a good and simple reliable filesystem that actually fits in with the others. ZFS is what we're stuck with till then.
- swinglock 4y ago
  Some of them are grounded in Linux politics. I have hope in bcachefs but best not rush, we've all seen btrfs.
  - arghwhat 4y ago
    ZFS was never any prettier on BSD either, so wouldn't blame Linux in that. But yes, bcachefs is somewhat interesting. Or maybe btrfs manages to clean up their act one day.
    - fbhabbed 4y ago
      What's wrong with btrfs?
      - asdf123a 4y ago
        as with all things GPL, victim of FUD campaigns by corporate america.
        arghwhat 4y ago
        excuse me what
      - detaro 4y ago
        The parity-based RAID levels still are officially not safe for production, and overall many people don't quite trust it in more complex setups due to past bugs.
      - doublepg23 4y ago
        Here’s an excellent run down that’s somewhat recent: https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/?amp=1 https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
      - sillystuff 4y ago
        It depends on your use case. BTRFS still has deficiencies in how it does quotas (significantly slows down fs if you enable quotas). BTRFS raid 5 has a write hole like traditional raid 5. And, there is a problem that sometimes occurs with individual extents when you use dedup. One of the dedup tools predicts that the issue will occur and will skip dedupe on such extents. There were RFCs on proposals to address both the write hole and quota issues on LWN this year, with the write hole fix already having draft patches see "raid tree". BTRFS is fine if you are not doing things that can hit those edges.
    - blacklion 4y ago
      ZFS on FreeBSD was very pretty, till Linux guys added adb and other Linux-specific features.
- masklinn 4y ago
  > ZFS is not the simplest solution to the problems that "ought to be solved" What are simpler solutions to the problems that ought to be solved?
  - arghwhat 4y ago
    A CoW filesystem itself is not much more complicated than a plain filesystem. Or maybe a CoW softraid, with the filesystem existing at a different layer. ZFS has countless bonus tunables, several types of caching distinct from the kernel VFS cache, its own write logs and special devices, multiple levels of topology (datasets in a pool consisting of vdevs consisting of drives), deduplication, compression, etc. It is also not at all user friendly. When set up right (and no changing your mind on setup), and when fed enough resources, it does it's job well, but simple or elegant cannot describe it.
    - klysm 4y ago
      I completely agree with that assessment. The core ideas behind how the CoW work are elegant, but the implementation is anything but elegant.
    - masklinn 4y ago
      You didn't answer the question. You can't claim that there are simpler solutions then not actually provide a simpler solution. Which handwaving is not. > A CoW filesystem itself is not much more complicated than a plain filesystem. And yet there isn't one out there, there's pretty much only ZFS and BTRFS, the latter having been in a state of almost-but-not-actually-working for over a decade now. bcachefs is the only contender and it remains a single-developer effort with little mainlining progress in the last few years.
      - laumars 4y ago
        There’s also hammerfs. I’ve not used that though. I think the complaints levelled against ZFS is a little unfair though. I agree that there are more elegant ways to implement ZFS but actually what we have already works really damn well. And the comments about the CLI being hard to use is weird because having used a hell of a lot of different file systems over the years (including BtrFS), I’ve found ZFS to be remarkably easy. ZFS has saved me from a number of hardware failures. If it really were as bad as the comments on here have made out, it’s have lost data several times over.

nix23 4y ago

>On the other side, ZFS is an overly complicated behemoth, that wants direct access to the block device. Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. So both serve different use-cases. Na...it's not overly complicated for what it is, but yes it is a behemoth. >that wants direct access to the block device. Yes for high-performance "enterprise"-setup's it is preferable, but absolutely not needed. > Meanwhile `muxfs` works with any already existing file-system (local or remote) and just provides the checksums. That i think is the winning point here, just add bit-rot protection to ffs.

magicalhippo 4y ago

> that wants direct access to the block device You can set up a ZFS pool backed by files[1]. Probably not something you should do with data you really care about, but it's possible. [1]: https://linux.die.net/man/8/zpool https://linux.die.net/man/8/zpool (Virtual Devices)