Why not FUSE ZFS?

[Dmitri Nikulin]

I got to thinking, there is a lot of debate raging over whether ZFS or
DFS (my tentative nickname for the alternative) is a better priority
for development. I was previously on the ZFS camp, thinking a good
on-disk file system which is gaining a lot of hype and adoption would
be a very good bargaining chip in DragonFly's pile.
Now it just occurred to me we can have ZFS for the nominal price of
supporting FUSE. It's not as fast as a pure kernel version, of course,
but Matt says he wants userland file systems anyway and FUSE is a
de-facto standard for that. Even NetBSD's puffs now has a 'refuse'
compatibility kit. FreeBSD also has FUSE support. DragonFly can
support FUSE by wrapping SYSLINK as is already planned, and this
immediately gives it a lot of file systems currently beyond reach.
FreeBSD has kernel support well on the way, and it seems to be ahead
of the FUSE version. I don't know how useful this is to DragonFly (as
far as being less work to port than the Solaris code, or being
portable to userland).
Not sure about the license issues of the FUSE ZFS, but purely
pragmatically, it may be the 'right' thing to develop rather than try
to port a kernel implementation into the DragonFly kernel. Like Matt
said, even if DragonFly doesn't survive, a lot of its technology will,
and developing things in the userland is precisely the way to ensure
that's what happens. It seems almost obvious that this is how ZFS
should be approached too, and it's already well on the way.
---
Dmitri Nikulin
Centre for Synchrotron Science
Monash University
Victoria 3800, Australia