From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Versioning file system Date: Mon, 18 Jun 2007 03:45:24 -0600 Message-ID: <20070618094524.GF5181@schatzie.adilger.int> References: <46731169.2090002@hawkeye.stone.uk.eu.org> <467314E2.9010306@zytor.com> <20070616145337.GA13391@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: alan , "H. Peter Anvin" , Jack Stone , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, viro@zeniv.linux.org.uk To: =?iso-8859-1?Q?J=F6rn?= Engel Return-path: Received: from mail.clusterfs.com ([206.168.112.78]:35778 "EHLO mail.clusterfs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758825AbXFRJp2 (ORCPT ); Mon, 18 Jun 2007 05:45:28 -0400 Content-Disposition: inline In-Reply-To: <20070616145337.GA13391@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Jun 16, 2007 16:53 +0200, J=F6rn 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 operation= s to > > >manage revisions) and atomic snapshots (for backup.) > >=20 > > ZFS is the cool new thing in that space. Too bad the license makes= it=20 > > hard to incorporate it into the kernel. >=20 > It may be the coolest, but there are others as well. Btrfs looks goo= d, > 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. >=20 > 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 multipl= e people working on getting it solid, scalable (parallel readers/writers = on lots of CPUs), robust (checksums, failure localization), recoverable, e= tc. I thought Val's FS summits were designed to get developers to collabora= te, but it seems everyone has gone back to their corners to work on their o= wn filesystem? Working on getting hooks into DM/MD so that the filesystem and RAID lay= ers can move beyond "ignorance is bliss" when talking to each other would b= e great. Not rebuilding empty parts of the fs, limit parity resync to pa= rts of the fs that were in the previous transaction, use fs-supplied checks= ums to verify on-disk data is correct, use RAID geometry when doing allocat= ions, 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