lkml.org 
[lkml]   [2007]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Versioning file system
    On Jun 16, 2007  16:53 +0200, Jörn Engel wrote:
    > On Fri, 15 June 2007 15:51:07 -0700, alan wrote:
    > > >Thus, in the end it turns out that this stuff is better handled by
    > > >explicit version-control systems (which require explicit operations to
    > > >manage revisions) and atomic snapshots (for backup.)
    > >
    > > ZFS is the cool new thing in that space. Too bad the license makes it
    > > hard to incorporate it into the kernel.
    >
    > It may be the coolest, but there are others as well. Btrfs looks good,
    > nilfs finally has a cleaner and may be worth a try, logfs will get
    > snapshots sooner or later. Heck, even my crusty old cowlinks can be
    > viewed as snapshots.
    >
    > If one has spare cycles to waste, working on one of those makes more
    > sense than implementing file versioning.

    Too bad everyone is spending time on 10 similar-but-slightly-different
    filesystems. This will likely end up with a bunch of filesystems that
    implement some easy subset of features, but will not get polished for
    users or have a full set of features implemented (e.g. ACL, quota, fsck,
    etc). While I don't think there is a single answer to every question,
    it does seem that the number of filesystem projects has climbed lately.

    Maybe there should be a BOF at OLS to merge these filesystem projects
    (btrfs, chunkfs, tilefs, logfs, etc) into a single project with multiple
    people working on getting it solid, scalable (parallel readers/writers on
    lots of CPUs), robust (checksums, failure localization), recoverable, etc.
    I thought Val's FS summits were designed to get developers to collaborate,
    but it seems everyone has gone back to their corners to work on their own
    filesystem?

    Working on getting hooks into DM/MD so that the filesystem and RAID layers
    can move beyond "ignorance is bliss" when talking to each other would be
    great. Not rebuilding empty parts of the fs, limit parity resync to parts
    of the fs that were in the previous transaction, use fs-supplied checksums
    to verify on-disk data is correct, use RAID geometry when doing allocations,
    etc.

    Cheers, Andreas
    --
    Andreas Dilger
    Principal Software Engineer
    Cluster File Systems, Inc.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-18 11:47    [W:0.024 / U:0.680 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site