Linux filesystem development
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Karel Zak <kzak@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	serue@us.ibm.com, containers@lists.osdl.org,
	linux-fsdevel@vger.kernel.org, util-linux-ng@vger.kernel.org,
	Al Viro <viro@ftp.linux.org.uk>
Subject: Re: How to query mount propagation state?
Date: Tue, 17 Apr 2007 00:38:46 -0700	[thread overview]
Message-ID: <1176795527.2813.59.camel@ram.us.ibm.com> (raw)
In-Reply-To: <20070416210739.GD4978@petra.dvoda.cz>

On Mon, 2007-04-16 at 23:07 +0200, Karel Zak wrote:
> On Mon, Apr 16, 2007 at 10:39:46AM -0700, Ram Pai wrote:
> 
> > This patch disambiguates multiple mount-instances of the same
> > filesystem (or part of the same filesystem), by introducing a new
> > interface /proc/mounts_new. The interface has the following format.
>             ^^^^^^^^^^^^^^
>  ... odd name. What will be the name for a next generation?
>  "/proc/mounts_new_new"? :-)
> 

that was the name I came up with 6 months back :-). Yes It should be
something more appropriate. Maybe /proc/mounts_1 ? The next generation
one would be /proc/mounts_2 ? Suggestion?


> > 'cat /proc/mounts' shows the following:
> > /dev/root /mnt ext2 rw 0 0
> > /dev/root /tmp1 ext2 rw 0 0
> > 
> > NOTE: The above mount entries, do not indicate that /tmp1 contains the same
> > directory tree as /var/tmp.
> > 
> > But 'cat /proc/mounts_new' shows us the following:
> > 0x6200 /mnt /var ext2 rw 0 0
> > 0x6200 /tmp1 /var/tmp ext2 rw 0 0
> 
>  Can't you purely and simply add the fsid= option to /proc/mounts?
> 
>  /dev/root /mnt ext2 rw,fsid=0x6200 0 0 
>  /dev/root /mnt ext2 rw,fsid=0x6200 0 0
> 
>  I think you can do it without a negative impact to userspace.

ok. 

> 
> > This patch introduces a new proc interface that exposes all the propagation 
> > trees within the namespace.
> 
>  Good idea.
> 
> > It walks through each off the mounts in the namespace, and prints the following information.
> > 
> > mount-id: a unique mount identifier
> > dev-id : the unique device used to identify the device containing the filesystem
>   ^^^^
>  Why not major:minor?

	Thinking about it, I feel we dont need this field at all. Basically we
need a field that can be keyed-upon to find the corresponding record
in /proc/mounts_1. mount-id can be used as the matching field, provided
we add the mount-id field to /proc/mounts_1.
agree?

RP

> > path-from-root: mount point of the mount from /
> > path-from-root-of-its-sb: path from its own root dentry.
> > propagation-flag: SHARED, SLAVE, UNBINDABLE, PRIVATE
> > peer-mount-id: the mount-id of its peer mount (if this mount is shared)
> > master-mount-id: the mount-id of its master mount (if this mount is slave)
> 
> > Example:
> > Here is a sample output of cat /proc/$$/mounts_propagation
> > 
> > 0xa917800 0x1 / / PRIVATE
> > 0xa917200 0x6200 / / PRIVATE
> > 0xa917180 0x3 /proc / PRIVATE
> > 0xa917f80 0xa /dev/pts / PRIVATE
> > 0xa917100 0x6210 /mnt / SHARED peer:0xa917100
> > 0xa917f00 0x6210 /tmp /1 SLAVE master:0xa917100
> > 0xa917900 0x6220 /mnt/2 / SHARED peer:0xa917900
> 
>  Same thing (although the mounts_propagation makes more sense than
>  mount_new from my point of view). 
> 
>  cat /proc/mounts (or /proc/$$/mounts)
> 
>  /dev/root /mnt ext2 rw,mid=0xa917100,did=0x6210,prop=SHARED,peer=0xa917100
> 
> 
>  my $0.02...
> 
>     Karel
> 


      reply	other threads:[~2007-04-17  7:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-16 10:34 How to query mount propagation state? Miklos Szeredi
     [not found] ` <E1HdOXG-0006pf-00-VFwzv6uONVrxNFs70CDYszOMxtEWgIxa@public.gmane.org>
2007-04-16 17:39   ` Ram Pai
2007-04-16 19:16     ` Serge E. Hallyn
2007-04-17  6:55       ` Ram Pai
2007-04-16 21:07     ` Karel Zak
2007-04-17  7:38       ` 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=1176795527.2813.59.camel@ram.us.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=serue@us.ibm.com \
    --cc=util-linux-ng@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