From mboxrd@z Thu Jan 1 00:00:00 1970 From: Goswin von Brederlow Subject: Re: [fuse-devel] delta filesystem prototype Date: Sun, 01 Mar 2009 11:17:09 +0100 Message-ID: <87eixhfsyi.fsf@frosties.localdomain> References: <87sklyh3wu.fsf@frosties.localdomain> <200903010138.39329.bs_lists@aakef.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: fuse-devel@lists.sourceforge.net, Goswin von Brederlow , Miklos Szeredi , linux-fsdevel@vger.kernel.org To: Bernd Schubert Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:55500 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751296AbZCAKRP (ORCPT ); Sun, 1 Mar 2009 05:17:15 -0500 In-Reply-To: <200903010138.39329.bs_lists@aakef.fastmail.fm> (Bernd Schubert's message of "Sun, 1 Mar 2009 01:38:38 +0100") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Bernd Schubert writes: > On Saturday 28 February 2009, Goswin von Brederlow wrote: >> Miklos Szeredi writes: >> > Here is my first try at a "delta" filesystem. It takes two >> > directories, one of which is a read-only base, and the other is where >> > the differences are stored. It stores data, metadata and directory >> > modifications without copying up whole files from the read-only >> > branch. >> > >> > The layout of the delta store may look similar to the writable branch >> > of a union fs, but this is basically just coincidence (it was easier >> > to start out this way). >> > >> > Currently it's implemented with fuse and it's not optimized at all, so >> > performance may suck in some cases. But I think this is a useful >> > concept and a better model, than trying to fit writable branches into >> > a union filesystem. >> > >> > Comments, bug reports are welcome. >> > >> > Thanks, >> > Miklos >> >> Wouldn't it make more sense to start with unionfs-fuse and add a delta >> feature to it? unionfs-fuse already has all you need except that it >> will copy the whole file (if on a read-only branch) on write. > > Well yes, but it would need to be configurable by the user. IMMHO, the 'delta' > ansatz has a big problem - what happens if the admin decides to modify the > underlying ro-branch, which is a distribution chroot seen by all clients as > their '/'? Any time files may be modified or even deleted on this branch when > the admin does an update. > This is also the exactly the problem why none of the kernel unionfs > implementation fits my needs and why I started to work on unionfs-fuse. Only, > the delta approach makes it even worse ;) > > > Cheers, > Bernd Obviously with delta storage the underlying branches really MUST be read-only. As for configuration I see no problem in clasifying a branch as RO, RW or D. If the user wants a modifiable RO branch then he can not have any D branch. Easy enough. MfG Goswin