From mboxrd@z Thu Jan 1 00:00:00 1970 From: hooanon05@yahoo.co.jp Subject: Re: [fuse-devel] delta filesystem prototype Date: Sat, 07 Mar 2009 18:16:15 +0900 Message-ID: <8773.1236417375@jrobl> 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> <871vt9iu21.fsf@frosties.localdomain> Cc: Miklos Szeredi , bs_lists@aakef.fastmail.fm, fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org To: Goswin von Brederlow Return-path: Received: from vsmtp04.dti.ne.jp ([202.216.231.139]:56945 "EHLO vsmtp04.dti.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752753AbZCGJQh (ORCPT ); Sat, 7 Mar 2009 04:16:37 -0500 In-Reply-To: <871vt9iu21.fsf@frosties.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Goswin von Brederlow: > > 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. ::: > 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). Agreed. While Miklos seems to dislike the inum table, it is necessary I think. J. R. Okajima