Plans for 1.8+ (2.0?)

[Chris Csanady]

On 2/12/07, Matthew Dillon <dillon at apollo.backplane.com> wrote:
    It would also be possible to assign redundancy, whereby two (or more)
    chunks are considered to be mirrors of each other.
Are you also considering redundancy beyond basic mirroring?  Over an
unreliable network, it would be desirable to mirror data at least
three ways, and this gets very expensive storage wise.  While it is
computationally expensive today, I think it would be very useful to
support Reed-Solomon ECC blocks.  Computation is cheaper than network
I/O in many cases, and will only become more so in the future.
Also, for anonymous clustering, encryption seems like a necessity as
well.  Or, at least something that should be considered in the design
stage.
    You would want such a filesystem to
    operate at full speed, as if it were just on the local disk.
However, it would be good to have an option to require that data be on
redundant storage before returning.  (At least two copies, perhaps one
on another cluster node on the local LAN.)  After this is done,
perhaps you could distribute the data and ECC blocks to several
machines across the network.
    ZFS does some of the things we want.  Much of what I described is
    ZFS-like.  The problem though is that ZFS does not handle the cluster
    aspects of the filesystem that we absolutely have to handle, and the
    more I look at ZFS the more I think it would take longer to port it
    then it would to write one from scratch.
Are you talking about the time to port it and make it useful as a
clusterable filesystem?
To do a straight port should be quite easy for one such as yourself.
The code is very portable, and your VFS work should make it even
easier.  Or is there some particular hangup for a possible port?  In
any case, I would not be surprised to find a message on this list
detailing a ZFS port that you did over some weekend.
While I don't want it to distract you from the more important goals, I
think a ZFS port would be well worth the minimal time investment to
get it to the point where someone else could pick it up.  It would
also be a great selling point.  Since DragonFly doesn't even have a
journalling filesystem, this seriously limits its utility, and that is
really unfortunate.
Chris

--
Matt, sorry about the direct reply; I meant to send it to the list instead.