Plans for 1.8+ (2.0?)

[Dmitri Nikulin]

On 2/13/07, Justin C. Sherrill <justin at shiningsilence.com> wrote:
It has benefits that go beyond clustering ability; while it may be more
work to convert ZFS for clustering, I can't imagine a homegrown filesystem
is necessarily going to have the same amount of documentation, toolsets,
or external support.
Why does nobody seem to mention interoperability? With some BSDs and
even Linux stepping up to ZFS support, we'll see a boom in the FS'
deployment. And it's a really strong case for DragonFly if it can
dual-boot on those systems and use the ZFS well. DragonFly's
distributed file system quite probably won't be supported by any other
system at all, because no other system has the foundations for it.
Less interoperability means less users which implies less developers,
which tends to lead nowhere. A great file system is a great bargaining
chip for operating system adoption, especially if it's the same file
system the user already has.
I still can't really imagine how ZFS could take longer to port than a
comparably high-tech file system would be to write. Anything of
similar scope and complexity is going to be just as large, because
ZFS' engineers had no shortage of time, resources and intelligence, so
they probably did a pretty good job as far as code sanity. A new file
system will be partly wheel reinvention, a lot of raw implementation
and testing work, and end up being either much simpler (and missing
some of the best functionality) or at least as large as ZFS' code is
already (and therefore take longer to write than it would be to just
change some parts to fit DragonFly).
Am I missing something there?

---
Dmitri Nikulin
Centre for Synchrotron Science
Monash University
Victoria 3800, Australia