LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: akpm@linux-foundation.org
Cc: miklos@szeredi.hu, viro@zeniv.linux.org.uk, linuxram@us.ibm.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/6] vfs: mountinfo update
Date: Fri, 14 Mar 2008 09:17:39 +0100	[thread overview]
Message-ID: <E1Ja56h-0003MU-Ok@pomaz-ex.szeredi.hu> (raw)
In-Reply-To: <20080313155315.6eb9942e.akpm@linux-foundation.org> (message from Andrew Morton on Thu, 13 Mar 2008 15:53:15 -0700)

> diffstat for all seven patches is:
> 
>  Documentation/filesystems/proc.txt |   35 +++++
>  fs/dcache.c                        |  101 +++++++++++---
>  fs/namespace.c                     |  182 ++++++++++++++++++++++-----
>  fs/pnode.c                         |  131 ++++++++++++++++++-
>  fs/pnode.h                         |   15 +-
>  fs/proc/base.c                     |  121 +++++++++--------
>  fs/seq_file.c                      |   92 +++++++++++--
>  include/linux/dcache.h             |    5 
>  include/linux/mnt_namespace.h      |   12 +
>  include/linux/mount.h              |    2 
>  include/linux/seq_file.h           |    7 +
>  11 files changed, 559 insertions(+), 144 deletions(-)
> 
> that's a mountain of tricksy new core-kernel code just for some /proc file.
> 
> Is this all really justifiable?

This is an approximate order of added features from most complex to
least complex:

 1) basic info about mount propagation
 2) root of the mount (source directory of bind)
 3) disambiguating reachable mounts from unreachable (/proc/mounts
    under chroot is a mess, and people are afraid to fix it:
    http://lkml.org/lkml/2007/4/17/271)
 4) showing "dominating group" which intersects with current namespace/root
 5) allocating ID's from IDR pools instead of ever increasing 64bit counters
 6) showing ID of mount and parent mount
 7) st_dev of mount

1, 2, 3 and 6 we definitely want.  Al wants 4.  I think 5 is useful
for readability, but not absolutely necessary.

All in all, I think there's very little that we can do, without
throwing out the baby with the bathwater.

Also compare this with the number of lines and mind boggling
complexity added for the mount propagation stuff, which is still very
little used years after it's introduction.  Possibly because some of
the infrastructure is still missing from kernel as well as userspace
to make it all really useful.  And I think this patch set goes towards
getting that infrastructure in place.

Possibly mount propagation will remain on the fringe for ever, in
which case a big chunk of this patch set (1 and 4) also end up being
useless.  The worst that can happen is that we end up adding some
#ifdef CONFIG_MOUNT_PROPAGATION clutter to namespace.c.

Miklos

  reply	other threads:[~2008-03-14  8:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13 21:26 Miklos Szeredi
2008-03-13 21:26 ` [patch 1/6] vfs: mountinfo -mm fix Miklos Szeredi
2008-03-13 21:26 ` [patch 2/6] vfs: pnode cleanup Miklos Szeredi
2008-03-19 11:16   ` Al Viro
2008-03-19 11:48     ` Miklos Szeredi
2008-03-13 21:26 ` [patch 3/6] vfs: mountinfo stable peer group id Miklos Szeredi
2008-03-19 11:48   ` Al Viro
2008-03-19 16:41     ` Miklos Szeredi
2008-03-19 18:20       ` Al Viro
2008-03-19 18:37         ` Miklos Szeredi
2008-03-20 21:43           ` Al Viro
2008-03-21  8:57             ` Miklos Szeredi
2008-03-22  3:49             ` Al Viro
2008-03-22  3:54               ` Al Viro
2008-03-22  4:11               ` Al Viro
2008-03-22  4:56                 ` Al Viro
2008-03-30 19:33                 ` Ram Pai
2008-03-24  8:50             ` Ram Pai
2008-03-24  8:54               ` Christoph Hellwig
2008-03-24  9:53               ` Al Viro
2008-03-22 16:27           ` Al Viro
2008-03-24  8:19             ` Ram Pai
2008-03-24  9:34               ` Al Viro
2008-03-13 21:26 ` [patch 4/6] vfs: mountinfo show dominating " Miklos Szeredi
2008-03-19 11:37   ` Al Viro
2008-03-19 12:03     ` Miklos Szeredi
2008-03-19 12:19       ` Miklos Szeredi
2008-03-19 12:41         ` Al Viro
2008-03-19 13:07           ` Miklos Szeredi
2008-03-13 21:26 ` [patch 5/6] vfs: optimization to /proc/<pid>/mountinfo patch Miklos Szeredi
2008-03-19 11:56   ` Al Viro
2008-03-19 16:56     ` Miklos Szeredi
2008-03-13 21:26 ` [patch 6/6] vfs: mountinfo: only show mounts under tasks root Miklos Szeredi
2008-03-19 12:12   ` Al Viro
2008-03-19 12:25     ` Miklos Szeredi
2008-03-13 22:53 ` [patch 0/6] vfs: mountinfo update Andrew Morton
2008-03-14  8:17   ` Miklos Szeredi [this message]
2008-03-14 19:29     ` Ram Pai

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=E1Ja56h-0003MU-Ok@pomaz-ex.szeredi.hu \
    --to=miklos@szeredi.hu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [patch 0/6] vfs: mountinfo update' \
    /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

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