From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Shaya Potter <spotter@cs.columbia.edu>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Jan Blunck <j.blunck@tu-harburg.de>
Subject: Re: [RFC][PATCH 0/15] VFS based Union Mount
Date: Wed, 18 Apr 2007 12:49:47 +0530 [thread overview]
Message-ID: <20070418071947.GC5870@in.ibm.com> (raw)
In-Reply-To: <4624FC38.6040503@cs.columbia.edu>
On Tue, Apr 17, 2007 at 12:56:24PM -0400, Shaya Potter wrote:
> Bharata B Rao wrote:
>
> >No. foo is not visible. While looking for a file in a union mounted
> >directory, the lookup starts from the topmost directory and proceeds
> >downwards if the file isn't present the top layers. If a whiteout is
> >found in any of the top layers, the lookup is abondoned and -ENOENT
> >is removed. Thus until a whiteout exists in any upper layer for
> >a corresponding file in the lower layer, the lower layer file remains
> >hidden until the whiteout is removed.
> >
> >However in the case of dir-c containing foo, the foo(from dir-c) will
> >become
> >visible after union mounting dir-c on top of dir-b and dir-a.
>
> ok, so the major limitation of this approach is that the top most layer
> has to either be, ext2, ext3 or tmpfs (in patch), and most likely not
> NFS (assumption is that NFS has no conception of the whiteout type of
> file).
I haven't played with union mounts with NFS. Hence would let Jan answer
this. However note that union mount provides a writable union only
if the filesystem supports the notion of whiteouts.
> One thing the unionfs people are doing w/ their ODF approach, is
> within the ODF fs, they have a special inode that is the "whiteout"
> inode, and when they create a whiteout, they just create a hardlink from
> the dentry they want to whiteout to the "whiteout inode". could that be
> a worthwhile approach instead of the whiteout file type? (i.e. many
> file systems support the concept of a hard link).
We we thinking something on similar lines as noted in our documentation.
Right now we maintain one inode for every whiteout. We were planning to
have a single whiteout inode and have all whiteout dentries point to this.
But here again we were thinking of having every filesystem support
this whiteout inode type.
Anyway I will have a look at ODF from unionfs to see how this is done.
>
> I ask, because using union in a diskless environment. Imagine pxe
> booting a kernel/initramfs and then using union to create a real root fs
> (shared lower layer, private rw upper layer, ala live cds). Which
> brings up a different point, with unionfs, one can pivot_root into it,
> can one do the same for these "union mounts"? Don't know enough about
> the VFS to know if this should "just work" or might be a problem.
I would assume that it should 'just work'. But right now it is not working.
Our code is not yet ready to correctly work with move mounts. Since pivot_root
has semantics similar to move mounts, pivot_root is also not working. Also
chroot to a union mount point is also not working atm. We will be working
to get all these right.
Regards,
Bharata.
prev parent reply other threads:[~2007-04-18 7:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-17 13:14 [RFC][PATCH 0/15] VFS based Union Mount Bharata B Rao
2007-04-17 13:16 ` [RFC][PATCH 1/15] Add union mount documentation Bharata B Rao
2007-04-17 13:17 ` [RFC][PATCH 2/15] Add a new mount flag (MNT_UNION) for union mount Bharata B Rao
2007-04-17 13:17 ` [RFC][PATCH 3/15] Add the whiteout file type Bharata B Rao
2007-04-17 13:18 ` [RFC][PATCH 4/15] Add config options for union mount Bharata B Rao
2007-04-17 13:19 ` [RFC][PATCH 5/15] Introduce union stack Bharata B Rao
2007-04-17 22:08 ` Serge E. Hallyn
2007-04-18 3:27 ` Bharata B Rao
2007-04-17 13:20 ` [RFC][PATCH 6/15] Union-mount dentry reference counting Bharata B Rao
2007-04-17 13:20 ` [RFC][PATCH 7/15] Union-mount mounting Bharata B Rao
2007-04-17 13:21 ` [RFC][PATCH 8/15] Union-mount lookup Bharata B Rao
2007-04-17 13:22 ` [RFC][PATCH 9/15] Simple union-mount readdir Bharata B Rao
2007-04-17 13:22 ` [RFC][PATCH 10/15] In-kernel file copy between union mounted filesystems Bharata B Rao
2007-04-17 13:23 ` [RFC][PATCH 11/15] VFS whiteout handling Bharata B Rao
2007-04-17 13:23 ` [RFC][PATCH 12/15] ext2 whiteout support Bharata B Rao
2007-04-17 13:24 ` [RFC][PATCH 13/15] ext3 " Bharata B Rao
2007-04-17 13:24 ` [RFC][PATCH 14/15] tmpfs " Bharata B Rao
2007-04-17 13:25 ` [RFC][PATCH 15/15] Union-mount changes for NFS Bharata B Rao
2007-04-17 14:35 ` [RFC][PATCH 0/15] VFS based Union Mount Shaya Potter
2007-04-17 16:30 ` Bharata B Rao
2007-04-17 16:56 ` Shaya Potter
2007-04-18 7:19 ` Bharata B Rao [this message]
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=20070418071947.GC5870@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=j.blunck@tu-harburg.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=spotter@cs.columbia.edu \
/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