> 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-fsdevel"
> in
> the body of a message to
majordomo@vger.kernel.org
> More majordomo info at
http://vger.kernel.org/majordomo-info.html
>
>
>
