From: Ram Pai <linuxram@us.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Al Viro <viro@ftp.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, util-linux-ng@vger.kernel.org
Subject: Re: Adding subroot information to /proc/mounts, or obtaining that through other means
Date: Thu, 21 Jun 2007 23:44:14 -0700 [thread overview]
Message-ID: <1182494654.2812.22.camel@ram.us.ibm.com> (raw)
In-Reply-To: <467AB5EE.3030909@zytor.com>
On Thu, 2007-06-21 at 10:31 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> >
> > Peter, I am not working on it currently. But i am interested in getting
> > it done. I have the seed set of patches which had Al Viro's ideas
> > incorporated. Infact those patches were sent on lkml 2 months back.
> > Shall we start with those patches?
> >
>
> Okay, so what I see in your patches are:
>
> > > 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)
>
> Other than cosmetic, I don't see anything terribly wrong with this,
> although getting a flag when the directory is overmounted would be nice.
>
> I guess I suggest a single comma-separated field with flags and optional
> ":argument":
>
> private
> shared:<peer>
> slave:<master>
> unbindable
> overmounted
>
> So we could end up with something like:
>
> rootfs / rootfs rw 0 0 0:1 / 1 private,overmounted
>
> ... where 1 is the mnt_id (sequence number).
>
> [Please see my other comments in this thread... basically I believe we
> should just add fields to /proc/mounts.]
I had two patches. The first patch added a new interface
called /proc/mounts_new and had the following format.
FSID mntpt root-dentry fstype fs-options
where FSID is a filesystem unique id
mntpt is the path to the mountpoint
root-dentry is the path to the dentry with respect to the root dentry of
the same filesystem.
fstype is the filesystem type
fs-options the mount options used.
the second patch made a /proc/propagation interface which had almost the
same fields, but also added fields to show the propagation type of the
mount as well as pointers to its peers and master depending on the type
of the mount.
I think the consensus seems to have a new interface /proc/make-a-name
which extends the interface provided by /proc/mounts but provides the
propagation state of the mounts too as well as disambiguate bind mounts.
Which makes sense.
Why not have something like this?
mnt-id FSID backing-dev mntpt root-dentry fstype
comma-separated-fs-options
and one of the fields in the comma-separated-fs-options indicates the
propagation type of the mount.
BTW: what is the need for overmounted flag? Do you mean two vfsmounts
mounted on the same dentry on the ***same vfsmount*** ?
RP
>
> -hpa
next prev parent reply other threads:[~2007-06-22 6:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-20 20:57 Adding subroot information to /proc/mounts, or obtaining that through other means H. Peter Anvin
2007-06-20 21:03 ` Al Viro
2007-06-20 21:20 ` H. Peter Anvin
2007-06-21 16:20 ` Ram Pai
2007-06-21 16:29 ` H. Peter Anvin
2007-06-21 17:20 ` Ram Pai
2007-06-21 17:31 ` H. Peter Anvin
2007-06-21 17:43 ` H. Peter Anvin
2007-06-22 6:44 ` Ram Pai [this message]
2007-06-22 7:06 ` H. Peter Anvin
2007-06-22 7:34 ` Ram Pai
2007-06-22 7:51 ` H. Peter Anvin
[not found] ` <20070625214640.GC29058@ram.us.ibm.com>
2007-06-25 22:00 ` [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree Ram Pai
2007-06-26 8:01 ` Karel Zak
2007-06-26 14:34 ` H. Peter Anvin
2007-06-30 9:44 ` Christoph Hellwig
2007-06-30 12:56 ` H. Peter Anvin
2007-07-11 10:24 ` Christoph Hellwig
2007-07-11 15:42 ` Ram Pai
2007-07-16 18:46 ` [RFC2 " Ram Pai
2007-06-20 22:24 ` Adding subroot information to /proc/mounts, or obtaining that through other means Karel Zak
2007-06-20 22:39 ` H. Peter Anvin
2007-06-20 22:33 ` Chuck Lever
2007-06-20 22:41 ` H. Peter Anvin
2007-06-20 22:48 ` Chuck Lever
2007-06-20 22:57 ` H. Peter Anvin
2007-06-20 23:02 ` Chuck Lever
2007-06-21 16:13 ` H. Peter Anvin
2007-06-21 16:49 ` Serge E. Hallyn
2007-06-21 16:51 ` H. Peter Anvin
2007-06-28 14:53 ` Pavel Machek
2007-06-28 15:36 ` H. Peter Anvin
2007-06-20 22:05 ` Karel Zak
2007-06-20 22:07 ` H. Peter Anvin
2007-06-20 22:41 ` Dr. David Alan Gilbert
2007-06-20 22:46 ` H. Peter Anvin
2007-06-21 19:14 ` Hans-Peter Jansen
2007-06-21 19:19 ` H. Peter Anvin
2007-06-20 22:55 ` Nix
2007-06-21 10:45 ` Miklos Szeredi
2007-06-21 19:42 ` Nix
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=1182494654.2812.22.camel@ram.us.ibm.com \
--to=linuxram@us.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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