From mboxrd@z Thu Jan 1 00:00:00 1970 From: Goswin von Brederlow Subject: Re: [fuse-devel] delta filesystem prototype Date: Sat, 07 Mar 2009 09:56:59 +0100 Message-ID: <87ab7xiuck.fsf@frosties.localdomain> References: <87sklyh3wu.fsf@frosties.localdomain> <200903010138.39329.bs_lists@aakef.fastmail.fm> <87eixhfsyi.fsf@frosties.localdomain> <87y6vlcr6p.fsf@frosties.localdomain> <87mybzd9nn.fsf@frosties.localdomain> <87zlfy95nn.fsf@frosties.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: goswin-v-b@web.de, fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org To: Miklos Szeredi Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:44309 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752010AbZCGI5E (ORCPT ); Sat, 7 Mar 2009 03:57:04 -0500 In-Reply-To: (Miklos Szeredi's message of "Fri, 06 Mar 2009 14:21:16 +0100") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Miklos Szeredi writes: > On Fri, 06 Mar 2009, Goswin von Brederlow wrote: >> > The most interesting is the directory and metadata deltas, which do >> > make a delta-fs like implementation much more effective and nicer as a >> > dumb union type filesystem. Mind, unionfs and aufs are rapidly >> > acquiring non-union traits, like inode number storage, virtual hard >> > links (not to speak of whiteouts). Which makes them all the more >> > hackish, I much prefer a conceptually clean solution. >> >> That is certainly something for unionfs-fuse as far as it isn't done >> already. Doesn't even need any delta algorithm, just seperate storage >> of metadata and normal data. Iirc Bernd already did look into >> preserving inodes in unionfs-fuse. > > At which point it's less of a union and more of a delta. A union is > taking two ordinary plain filesystems and merging them according to > some rules. A delta is having a plain filesystem and merging a > special format one into this. See where I'm going? > > My main question in all this is: does it make sense to keep the union > semantics and tack on various features into separate storage? Or is > it better to abandon the unioning altogether in favor of a more > efficient delta format? > > Thanks, > Miklos The union should be transparent to the user and applications. The problem is that some application do look at the inode number, m/a/ctime and so on. So to be transparent the metadata has to be handled in a union as well. If you want to call it a delta filesystem then fine. I would expect a delta filesystem to do deltaing of file content though, not just be able to track metadata changes seperate from file data. But that is nothing to fight over. MfG Goswin