linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).