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 10:03:18 +0100 Message-ID: <871vt9iu21.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> <639.1236388786@jrobl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , goswin-v-b@web.de, bs_lists@aakef.fastmail.fm, fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org To: hooanon05@yahoo.co.jp Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:48945 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752360AbZCGJDg (ORCPT ); Sat, 7 Mar 2009 04:03:36 -0500 In-Reply-To: <639.1236388786@jrobl> (hooanon's message of "Sat, 07 Mar 2009 10:19:46 +0900") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: hooanon05@yahoo.co.jp writes: > Miklos Szeredi: >> 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. > > I agree that the delta is a good approach. But it is for filedata only. > As I wrote in another mail, how do you support hardlinks on the lower > readonly layer? > > > J. R. Okajima Use a filename -> inode indirection and delta based on inode numbers. Although the you also have to consider the device id in case there are multiple filesystem mounted in your read-only branch. So filename -> (dev, inode). MfG Goswin