From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: Union mounts comparison with overlay file system prototype? Date: Fri, 25 Mar 2011 08:12:34 -0400 Message-ID: <4D8C86B2.2060902@redhat.com> References: <1300845590-14184-1-git-send-email-valerie.aurora@gmail.com> <4D8B4A6F.9040303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Valerie Aurora , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, Christoph Hellwig To: Szeredi Miklos Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 03/25/2011 07:38 AM, Szeredi Miklos wrote: > On Thu, Mar 24, 2011 at 2:43 PM, Ric Wheeler wrote: >> Can one or both of you summarize what we union mounts and overlay do better >> or worse? Do we need both or just one? > The semantics are very similar, the differences are in the implementation. > > Union mounts: > > - whiteout/opaque/fallthrough support in filesystems > - whiteout operation is atomic > - no dentry and inode duplication > - copy up on lookup and readdir > - does not support union of two read-only trees > - merged directory stored in upper tree > > Overlayfs > > - whiteout/opaque as xattrs > - whiteout operation is not atomic > - dentry and inode duplication(*) > - only copy up on modification > - supports union of two read-only trees > - merged directory not cached(**) > > (*) it's possible to eliminate inode duplication of non-directories > with some VFS modifications > (**) caching should be possible to do Thanks for the high level overview! Ric