From: Rob Landley <rob@landley.net>
To: linux-kernel@vger.kernel.org
Subject: Problems with /proc/mounts and statvfs (implementing df).
Date: Sat, 28 Oct 2006 15:37:06 -0400 [thread overview]
Message-ID: <200610281537.07145.rob@landley.net> (raw)
I'm trying to implement a df command that works based on /proc/mounts and
statvfs. To make this work, I need to be able to detect duplicate mounts
(including --bind mounts), and I need to be able to detect overmounted
filesystems.
Problem #1: mount --move doesn't reorder /proc/mounts.
My first naieve idea was to reverse the order of entries in /proc/mounts and
do simple string comparisons on the directory names to detect overmounts. An
example of why this doesn't work is in ubuntu 6.06, where "/proc" and "/sys"
get mounted from initramfs, then the new root (/dev/hda1 in my case) is
mounted after that, and the proc and sys mounts are "mount --move"d under
that. So they're before the current "/" in the /proc/mounts order, but
they've been moved under that mount anyway. It would be really nice if
mount --move would reorder /proc/mounts when the new parent filesystem is
after the old one in the list. (Another thing that depends on this to work
is "umount -a", which can't umount "/" in this case either because /proc
and /sys are still under it.)
In theory I can work around this by just having umount -a loop until
everything's unmounted (which is ugly), and by having df call statvfs on
everything and discard duplicate f_fsid entries (although with mount --move
it can still find the wrong entry mounted at a given mount point, but at
least this can filter sub-mounts and restricts the problem to direct
overmounts).
Problem #2: statfs() and statvfs() are returning 0 in the f_fsid.
What's the recommended way to detect --bind mounts or duplicate mounts? A df
command needs to know "these two mount points are in the same filesystem",
and according to the man pages there's supposed to be a unique identifier for
each filesystem.
The man page suggested that this was crippled to work around yet another
design flaw in NFS, but I tried doing it as root and still got 0 for all the
filesystems. (Not that setting the suid bit on the df command struck me as a
good solution.)
Any suggestions? (All this was done on the ubuntu 6.06 kernel. Will it make
a difference to try 2.6.19-rc3?)
Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
next reply other threads:[~2006-10-28 19:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-28 19:37 Rob Landley [this message]
2006-10-28 20:28 ` Problems with /proc/mounts and statvfs (implementing df) Rob Landley
2006-11-02 10:07 ` Ian Kent
2006-11-02 20:53 ` Rob Landley
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=200610281537.07145.rob@landley.net \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.