mount-2.12r-ggk.tar.gz

mount-2.12r-ggk.tar.gz

[Andries.Brouwer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

The present situation of util-linux and mount is not quite clear to me.
On kernel.org under utils/util-linux nothing has happened for over a year,
and there is also an empty utils/util-linux-ng.

Anyway, Dirk Gerrits, René Gabriël and Peter Kooijmans sent me
a patch to add support for shared subtrees to the mount from
util-linux 2.12r, and I put up the result for ftp at
ftp://ftp.win.tue.nl/pub/linux-local/utils/mount/mount-2.12r-ggk.tar.gz

They remark that it feels like a kernel bug that --make-unbindable
is not reset by --make-private and suggest the patch

--- pnode.old   2007-04-17 12:53:11.000000000 +0200
+++ pnode.c     2007-04-17 13:22:03.000000000 +0200
@@ -83,6 +83,8 @@
                mnt->mnt_master = NULL;
                if (type == MS_UNBINDABLE)
                        mnt->mnt_flags |= MNT_UNBINDABLE;
+               else
+                       mnt->mnt_flags &= ~MNT_UNBINDABLE;
        }
 }

(with white-space damage - my cut&paste).

Without this patch one needs the detour "--make-shared; --make-private"
in order to reset the "unbindable" flag for a private tree.

Andries



[By the way, this shared subtree stuff is a bit messy,
and impossible to support correctly by mount without help
from the kernel. So far the shared/slave/unbindable status
of mounts is not visible in /proc/mounts or /proc/$$/mountstats.
The above mount makes a feeble attempt to record these flags
in /etc/mtab, but will fail in any nontrivial situation.]

Re: mount-2.12r-ggk.tar.gz

[Karel Zak]

On Tue, Jun 19, 2007 at 02:38:59PM +0200, Andries.Brouwer@cwi.nl wrote:
> The present situation of util-linux and mount is not quite clear to me.
> On kernel.org under utils/util-linux nothing has happened for over a year,
> and there is also an empty utils/util-linux-ng.

 We use GIT for development, the utils/util-linux-ng is for releases.

  http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git
  http://userweb.kernel.org/~kzak/util-linux-ng/
  http://vger.kernel.org/vger-lists.html#util-linux-ng

> Anyway, Dirk Gerrits, René Gabriël and Peter Kooijmans sent me
> a patch to add support for shared subtrees to the mount from
> util-linux 2.12r, and I put up the result for ftp at
> ftp://ftp.win.tue.nl/pub/linux-local/utils/mount/mount-2.12r-ggk.tar.gz

 Hmm.. some distributions and also util-linux-ng already use Ram Pai's
 shared subtrees patch:

 http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commitdiff;h=389fbea536e4308d9475fa2a89e53e188ce8a0e3

> [By the way, this shared subtree stuff is a bit messy,
> and impossible to support correctly by mount without help
> from the kernel. So far the shared/slave/unbindable status
> of mounts is not visible in /proc/mounts or /proc/$$/mountstats.

 Unfortunately, you're right.

 We need something like /proc/PID/mounts_propagation
 (see 2nd patch in):
 http://www.mail-archive.com/util-linux-ng@vger.kernel.org/msg00136.html

> The above mount makes a feeble attempt to record these flags
> in /etc/mtab, but will fail in any nontrivial situation.]

 I don't think that mtab is a good place for this shared subtree
 stuff. The mtab needs to die.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: mount-2.12r-ggk.tar.gz

[Andries Brouwer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 2361 bytes --]

On Tue, Jun 19, 2007 at 04:15:28PM +0200, Karel Zak wrote:

>  We use GIT for development, the utils/util-linux-ng is for releases.

Aha - and there have not been any releases yet.

> > Anyway, Dirk Gerrits, René Gabriël and Peter Kooijmans sent me

I meant Dirk Gerrits, René Gabriëls and Peter Kooijmans, sorry

> > [By the way, this shared subtree stuff is a bit messy,
> > and impossible to support correctly by mount without help
> > from the kernel. So far the shared/slave/unbindable status
> > of mounts is not visible in /proc/mounts or /proc/$$/mountstats.
> 
>  Unfortunately, you're right.
> 
>  We need something like /proc/PID/mounts_propagation
>  (see 2nd patch in):
>  http://www.mail-archive.com/util-linux-ng@vger.kernel.org/msg00136.html

Hmm - mounts_new - very ugly. Reminds me of oldolduname and family.
I see that you followed up and said the right things.

> > The above mount makes a feeble attempt to record these flags
> > in /etc/mtab, but will fail in any nontrivial situation.]
> 
>  I don't think that mtab is a good place for this shared subtree
>  stuff. The mtab needs to die.

Perhaps. Perhaps not.

On the one hand I think there is a place for arbitrary user-space info
about mounted filesystems. With information about who mounted, and at what time.
What the icon is that should represent this filesystem. What resources are
associated to this mount, and which program must do the cleanup. Etc.
Today there is not much user-space info, but there is some.

On the other hand, the fact that the namespace is per-process
complicates matters. There is no natural location for a per-process mtab.
But maybe the easy solution is just to leave that to the users by giving
mount(8) an option "-M mtabfile".

What is missing is a way for user space to find out what the actual
kernel situation is, and that makes /etc/mtab imperfect. The right
implementation of "mount" (without options, roughly "cat /proc/mounts")
would be for mount to ask the kernel about all existing mounts,
merge the user space type information found in /etc/mtab, and give the result
to the user. (And update mtab if necessary.)

For the filesystem we have readdir() and stat() to find out about
the file hierarchy. I would like readmounts() and statmount() to find out
about the tree of mounts and the flags of each mount. Without using /proc.

Andries

Re: mount-2.12r-ggk.tar.gz

[Karel Zak]

On Tue, Jun 19, 2007 at 05:28:18PM +0200, Andries Brouwer wrote:
> > > The above mount makes a feeble attempt to record these flags
> > > in /etc/mtab, but will fail in any nontrivial situation.]
> > 
> >  I don't think that mtab is a good place for this shared subtree
> >  stuff. The mtab needs to die.
> 
> Perhaps. Perhaps not.
> 
> On the one hand I think there is a place for arbitrary user-space info
> about mounted filesystems. With information about who mounted, and at what time.
> What the icon is that should represent this filesystem. What resources are
> associated to this mount, and which program must do the cleanup. Etc.
> Today there is not much user-space info, but there is some.

 See also the "[RFC] obsoleting /etc/mtab" thread:
 http://www.mail-archive.com/util-linux-ng@vger.kernel.org/index.html#00208

    Karel


-- 
 Karel Zak  <kzak@redhat.com>

Re: mount-2.12r-ggk.tar.gz

[Andries Brouwer]

On Tue, Jun 19, 2007 at 08:51:25PM +0200, Karel Zak wrote:
> > >  I don't think that mtab is a good place for this shared subtree
> > >  stuff. The mtab needs to die.
> > 
> > Perhaps. Perhaps not.
> > 
> > On the one hand I think there is a place for arbitrary user-space info
> > about mounted filesystems. With information about who mounted, and at
> > what time. What the icon is that should represent this filesystem.
> > What resources are associated to this mount, and which program must do
> > the cleanup. Etc.
> > Today there is not much user-space info, but there is some.
> 
>  See also the "[RFC] obsoleting /etc/mtab" thread:
>  http://www.mail-archive.com/util-linux-ng@vger.kernel.org/index.html#00208

Good that I am not on that mailing list - I might have spent a lot of time
discussing.

I see that many people agree that there is the need to attach
some metadata to mounts. Good.
But they suggest storing that metadata in the kernel. Bad.
The kernel is not a storage place for random non-kernel-related data.

A good place is a file, like /etc/mtab (I suppose today /var/run/mtab
might be the appropriate place for system-wide mounts, and for
user-private mounts the user can, if she wishes, indicate her
favorite mtab file to use: "mount -M $HOME/foo/mtab3").

And the kernel needs non-procfs interfaces (namely syscalls)
that can tell a process about its mount environment: readmounts()
and statmount(). As soon as mount(8) can ask the kernel, then
the problem of non-up-to-date /etc/mtab, and incomplete /proc/mounts
has gone away.

Andries


[By the way, just like a single flat directory that contains all files
turned out to be a bad idea, a single flat structure that contains
all mounts will turn out soon to be a bad idea too. Some people use
thousands of mounts. So, also mounts must live in a tree-structured space.]