From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: fistgen-0.1.1 released (linux-2.6 support) Date: Mon, 02 Aug 2004 18:54:10 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1091498050.7483.8.camel@localhost.localdomain> References: <20040731195717.GA24760@mail.shareable.org> <200408021818.i72IIpoP003176@agora.fsl.cs.sunysb.edu> <20040802190817.GA11754@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Erez Zadok , linux-fsdevel@vger.kernel.org Return-path: Received: from opus.cs.columbia.edu ([128.59.20.100]:6637 "EHLO opus.cs.columbia.edu") by vger.kernel.org with ESMTP id S261184AbUHCB5T (ORCPT ); Mon, 2 Aug 2004 21:57:19 -0400 To: Jamie Lokier In-Reply-To: <20040802190817.GA11754@mail.shareable.org> List-Id: linux-fsdevel.vger.kernel.org On Mon, 2004-08-02 at 20:08 +0100, Jamie Lokier wrote: > Erez Zadok wrote: > > Right, it looks like you want to support version trees (branches off of > > branches, etc. ala CVS), as well as some ability to create composable views > > that mix and match version "forks." > > That is a complicated way of looking at it! > > > We considered supporting version trees, but frankly, couldn't come up with a > > compelling application for those that would justify the added complexity. > > Such version trees are complex and hard to manage, and the most users get > > really confused with version trees (CVS branch management is enough of a > > reason to mess up :-) > > > > Jamie, I'd love to get a detailed example of how one envisions using such a > > versioning system, so I can see how much our current work may support it, > > and what it'd take to make it do what you want. > > One uses it by typing "cp -a dir1 dir2" or "cp -r dir1 dir2". > > That's all. There are no user-visible versions, no branch > management, and no other commands. I have a "working" (relative term as performance sucks) fs that can do that. It combined a file system based out of fist's templates and a bit of hacking on ext3cow. basic idea is that ext3cow provided the individual file versioning semantic (and directories are just treated as containers) while the stackable fs managed the branching (and deciding when to version and the like). was able to build 4 kernels side by side w/o a problem. i.e. it was something along the lines of (from memory) # mkfs.ext3cow /dev/loop0 # mount -t ext3cow /dev/loop0 /mnt # mount -o bind /mnt /mnt1 # mount -o bind /mnt /mnt2 # mount -o bind /mnt /mnt3 # (cd /mnt ; tar xzf ~/linux.tar.gz) # mount -t branchfs -o new_branch=new,old_branch=,(some fist options) /mnt /mnt # cd /mnt # branch_ioctl new1 # mount -t branchfs -o new_branch=new2,old_branch=new,(some fist options) /mnt1 /mnt1 # mount -t branchfs -o new_branch=new2,old_branch=new,(some fist options) /mnt2 /mnt2 # mount -t branchfs -o new_branch=new2,old_branch=new,(some fist options) /mnt2 /mnt2 lots of issues w/ it, but it was able to do the above as (well as then build the kernels). the stackable fs stored a lot of meta data on the underlying fs (i.e. managing branches and the like) and it was my first attempt at doing it, so probably made a lot of mistakes and hence the bad performance. unfortunately been too busy working for msft this summer, so haven't had a chance to try some of my ideas on fixing it up. shaya