From: Ram Pai <linuxram@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Al Viro <viro@ftp.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 17/18] unbindable mounts
Date: Mon, 14 Nov 2005 11:18:17 -0800 [thread overview]
Message-ID: <1131995897.4269.24.camel@localhost> (raw)
In-Reply-To: <p73d5l545h9.fsf@verdi.suse.de>
On Sat, 2005-11-12 at 19:00, Andi Kleen wrote:
> Al Viro <viro@ftp.linux.org.uk> writes:
>
> > From: Ram Pai <linuxram@us.ibm.com>
> > Date: 1131402080 -0500
> >
> > A unbindable mount does not forward or receive propagation. Also unbindable
> > mount disallows bind mounts. The semantics is as follows.
> >
> > Bind semantics:
> > Its invalid to bind mount a unbindable mount.
> > Move semantics:
> > Its invalid to move a unbindable mount under shared mount.
> > Clone-namespace semantics:
> > If a mount is unbindable in the parent namespace, the corresponding
> > cloned mount in the child namespace becomes unbindable too. Note:
> > there is subtle difference, unbindable mounts cannot be bind mounted
> > but can be cloned during clone-namespace.
>
> What is it good for?
> Normally I would have expected that to be part of the description.
Its part of the documentation patch in the FAQ section.
Lets say we have the following mount tree.
root
/ \ \
mnt usr home
If I want to replicate this mount tree under /mnt a couple of times as
follows
root
/ | \
mnt usr home
/ | \
r1 r2 r3
/ | \ / | \ / | \
mnt usr home mnt usr home mnt usr home
than the series of commands to execute are
mount --rbind / /mnt/r1
mount --rbind / /mnt/r2
umount /mnt/r2/mnt/r1/mnt
umount /mnt/r2/mnt/r1/usr
umount /mnt/r2/mnt/r1/home
(or maybe just umount -l /mnt/r2/mnt/r1)
mount --rbind / /mnt/r3
umount -l /mnt/r3/mnt/r1
umount -l /mnt/r3/mnt/r2
note: as we have more of these mounts replicating the system tree to
a location within the system tree the number of umounts increase
linearly.
The situation becomes exponential in case the root mount and submounts
within it are shared. (the documentation patch explains that case).
Unbindable mounts help to keep this in check.
All you have to do is mark /mnt as unbindable and after which its just
a matter of one --rbind. All the unnecessary submounts get pruned
automatically.
This feature comes in handy if each user wants to mimic the entire
system tree and chroot to its replicate. Its kind of giving virtual
mount environment to the user.
RP
>
>
> -Andi (slightly worried about all these different mount variants. Hopefully
> you guys themselves can still keep them all in your heads)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2005-11-14 19:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-08 2:01 [PATCH 17/18] unbindable mounts Al Viro
2005-11-13 3:00 ` Andi Kleen
2005-11-14 19:18 ` Ram Pai [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=1131995897.4269.24.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=ak@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/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).