[mook]

That sounds about as modular as systemd: it's in theory modular, but it very much throws away the existing boundaries and has yet to see its new modules be adopted by external folks (if that were even possible, depending on interface stability).

I believe that the modularity will only proof itself when external (as in, from unrelated people) projects becomes established and we see how well the original project maintains compatibility.

(I must say I wonder how big the intersection of people-who-like-ZFS and people-who-like-systemd is; they seemed to originate from very different cliques but there's no reason people who like one would dislike the other…)

[p_l]

There's sufficiently strong dislike for systemd in the ZoL circles I moved around, because ZFS was all about making sure its rock solid and stable, while systemd has well-deserved reputation for breaking things often.

As for external clients for the layers, LustreZFS is a separate project though it had started with certain intersection of ZFS devs. However the general division of labour between layer is pretty strict (except for - now extinct - FreeBSD TRIM support), it's just that there isn't any work being done to use it outside of OpenZFS.

The boundaries are pretty clear, it's just that ZPL and ZVOL build up on all of them. Linux has /some/ related features, but nothing that was feature-parity: SPA roughly corresponds with MD/DM subsystem assuming certain plugins in use, DMU is very roughly the equivalent of OSD subsystem, but that one supports only SCSI OSD which has incompatible assumptions etc. - in fact, an OSD implementation on top of DMU should be pretty simple (main differences are due to DMU being a bit explicit on redundancy features, iirc).