From: Rob Landley <rob@landley.net>
To: Ian Kent <raven@themaw.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Problems with /proc/mounts and statvfs (implementing df).
Date: Thu, 2 Nov 2006 15:53:01 -0500 [thread overview]
Message-ID: <200611021553.01463.rob@landley.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0611021804290.15477@raven.themaw.net>
On Thursday 02 November 2006 5:07 am, Ian Kent wrote:
> On Sat, 28 Oct 2006, Rob Landley wrote:
>
> > 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.
>
> I need to do quite a bit with mount tables in autofs.
> You may wish to look at lib/mounts.c in autofs version 5.
I've fiddled with this area before (I wrote the current BusyBox mount
command), and after a day or so of banging on it I did eventually get it to
work.
It turns out that statvfs.f_fsid is completely useless. What you need to do
is a normal stat() on each path from /proc/mounts and look at the st_dev
member, which turns out to be unique for each mounted filesystem (including
tmpfs and /proc and /sys). So this lets you identify unique filesystems, and
then detecting --bind mounts and overmounts is just a question or matching up
the st_dev values.
The remaining question was, when there are multiple mount points statting to
the same st_dev, which one's path should df display for that filesystem when
you do a normal "df"? What I did is for each unique st_dev, look at the last
entry in /proc/mounts, find its block device string (returned by getmntent()
as mnt_fsname), and then back up to find the first entry with both the same
st_dev and the same block device string. Display that one, dump the rest.
(If it had a different block device it was an overmounted filesystem. If it
had the same block device but wasn't the first occurence, it was either a
duplicate mount or a --bind mounts.)
> Current state of play can be found in files located at
> http://www.kernel.org/pub/linux/daemons/autofs/v5.
In my case "http://landley.net/code/toybox/download/toybox-0.0.1.tar.bz2",
which is at best "embryonic" but if you do "make && mv toybox df && ./df"
that one command should work. (It's got a loooooooong way to go, I know...)
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
prev parent reply other threads:[~2006-11-02 20:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-28 19:37 Problems with /proc/mounts and statvfs (implementing df) Rob Landley
2006-10-28 20:28 ` Rob Landley
2006-11-02 10:07 ` Ian Kent
2006-11-02 20:53 ` Rob Landley [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=200611021553.01463.rob@landley.net \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
/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.