From: Jan Blunck <jblunck@suse.de>
To: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Bharata B Rao <bharata@linux.vnet.ibm.com>
Subject: Re: [RFC 12/26] ext2 white-out support
Date: Thu, 2 Aug 2007 12:26:31 +0200 [thread overview]
Message-ID: <20070802102631.GW5101@hasse.suse.de> (raw)
In-Reply-To: <20070731171159.GA27234@filer.fsl.cs.sunysb.edu>
On Tue, Jul 31, Josef Sipek wrote:
> > So you think that just because you mounted the filesystem somewhere else it
> > should look different? This is what sharing is all about. If you share a
> > filesystem you also share the removal of objects.
>
> The removal happens at the union level, not the branch level. Say you have:
>
> /a/
> /b/foo
> /c/foo
>
> And you mount /u1 as a union of {a,b}, and /u2 as union of {a,c}.
>
> $ find /u*
> /u1
> /u1/foo
> /u2
> /u2/foo
> $ rm /u1/foo # this creates whiteout for "foo" in /a
> $ find /u*
> /u1
> /u2
>
> Is that what you'd expect as a user? I don't think so.
>
Yes, although that might sound strange: you are sharing the topmost writable
layer. This is what I expect.
> > > store. We did an experiment with Unionfs, and moving the whiteout handling
> > > to effectively a "library" that did all the dirty work cleaned up the code
> > > considerably [2,3].
> >
> > Haven't checked if you could use ODF for a generic store for filesystems that
> > couldn't support whiteouts. This might be an interesting idea.
>
> Yes, since the ODF is completely separate, you can use _any_ filesystem and
> regardless of whether or not they support whiteouts.
Completely separate? It is totally tied to UnionFS and tries to work out
purely the problems that this kind of VFS emulating filesystems have.
next prev parent reply other threads:[~2007-08-02 10:26 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 16:13 [RFC 00/26] VFS based Union Mount (V2) Jan Blunck
2007-07-30 16:13 ` [RFC 01/26] [PATCH 14/18] shmem: convert to using splice instead of sendfile() Jan Blunck
2007-07-30 16:13 ` [RFC 02/26] VFS: Export dput_path() and path_to_nameidata() Jan Blunck
2007-07-30 16:13 ` [RFC 03/26] VFS: Make lookup_hash() return a struct path Jan Blunck
2007-07-30 16:13 ` [RFC 04/26] VFS: Make lookup_create() " Jan Blunck
2007-07-30 16:13 ` [RFC 05/26] VFS: cache_lookup() cleanup Jan Blunck
2007-07-30 16:13 ` [RFC 06/26] VFS: Make real_lookup() return a struct path Jan Blunck
2007-07-30 16:13 ` [RFC 07/26] VFS: Introduce dput() variante that maintains a kill-list Jan Blunck
2007-07-30 16:13 ` [RFC 08/26] VFS: Export lives_below_in_same_fs() Jan Blunck
2007-07-30 16:13 ` [RFC 09/26] linux/stat.h: Add the filetype white-out Jan Blunck
2007-07-30 16:13 ` [RFC 10/26] VFS white-out handling Jan Blunck
2007-07-30 16:13 ` [RFC 11/26] tmpfs white-out support Jan Blunck
2007-08-01 15:13 ` Hugh Dickins
2007-08-02 2:48 ` Matt Mackall
2007-07-30 16:13 ` [RFC 12/26] ext2 " Jan Blunck
2007-07-31 3:45 ` Theodore Tso
2007-07-31 7:44 ` Jan Blunck
2007-07-31 8:32 ` Andreas Dilger
2007-07-31 9:08 ` Jan Blunck
2007-07-31 10:53 ` Theodore Tso
2007-08-02 19:31 ` Pavel Machek
2007-07-31 16:36 ` Josef Sipek
2007-07-31 17:00 ` Jan Blunck
2007-07-31 17:11 ` Josef Sipek
2007-08-01 15:23 ` Dave Kleikamp
2007-08-01 18:44 ` Josef Sipek
2007-08-01 19:10 ` Dave Kleikamp
2007-08-01 19:33 ` Josef Sipek
2007-08-01 19:52 ` Dave Kleikamp
2007-08-01 22:06 ` Erez Zadok
2007-08-02 12:05 ` Jan Blunck
2007-08-02 11:55 ` Jan Blunck
2007-08-02 17:50 ` Jörn Engel
2007-08-02 5:24 ` Ph. Marek
2007-08-02 12:12 ` Jan Blunck
2007-08-02 10:26 ` Jan Blunck [this message]
2007-08-01 10:00 ` Hans-Peter Jansen
2007-08-01 11:43 ` Josef Sipek
2007-08-01 18:01 ` Jan Engelhardt
2007-07-31 17:03 ` Mark Williamson
2007-07-31 17:16 ` Josef Sipek
2007-08-01 17:58 ` Jan Engelhardt
2007-08-01 18:03 ` Josef Sipek
2007-07-30 16:13 ` [RFC 13/26] ext3 whiteout support Jan Blunck
2007-07-30 16:13 ` [RFC 14/26] union-mount: Documentation Jan Blunck
2007-07-30 16:13 ` [RFC 15/26] union-mount: Add union-mount mount flag Jan Blunck
2007-07-30 16:13 ` [RFC 16/26] union-mount: Introduce union_mount structure Jan Blunck
2007-08-06 5:57 ` Bharata B Rao
2007-07-30 16:13 ` [RFC 17/26] union-mount: Drive the union cache via dcache Jan Blunck
2007-07-30 16:13 ` [RFC 18/26] union-mount: Changes to the namespace handling Jan Blunck
2007-08-08 10:10 ` Bharata B Rao
2007-07-30 16:13 ` [RFC 19/26] union-mount: Make lookup work for union-mounted file systems Jan Blunck
2007-08-09 5:42 ` Bharata B Rao
2007-07-30 16:13 ` [RFC 20/26] union-mount: Simple union-mount readdir implementation Jan Blunck
2007-08-06 11:08 ` Bharata B Rao
2007-07-30 16:13 ` [RFC 21/26] union-mount: in-kernel file copy between union mounted filesystems Jan Blunck
2007-07-30 16:13 ` [RFC 22/26] union-mount: white-out changes for copy-on-open Jan Blunck
2007-07-30 16:13 ` [RFC 23/26] union-mount: copyup on rename Jan Blunck
2007-07-30 16:13 ` [RFC 24/26] union-mount: dont report EROFS for union mounts Jan Blunck
2007-07-30 16:13 ` [RFC 25/26] union-mount: Debug Infrastructure Jan Blunck
2007-07-30 16:13 ` [RFC 26/26] union-mount: Debug code Jan Blunck
2007-07-30 18:23 ` [RFC 00/26] VFS based Union Mount (V2) Al Boldi
2007-08-02 6:49 ` Bharata B Rao
2007-08-02 10:17 ` Jan Blunck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070802102631.GW5101@hasse.suse.de \
--to=jblunck@suse.de \
--cc=bharata@linux.vnet.ibm.com \
--cc=jsipek@fsl.cs.sunysb.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).