* Problems with /proc/mounts and statvfs (implementing df).
@ 2006-10-28 19:37 Rob Landley
2006-10-28 20:28 ` Rob Landley
2006-11-02 10:07 ` Ian Kent
0 siblings, 2 replies; 4+ messages in thread
From: Rob Landley @ 2006-10-28 19:37 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problems with /proc/mounts and statvfs (implementing df).
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
1 sibling, 0 replies; 4+ messages in thread
From: Rob Landley @ 2006-10-28 20:28 UTC (permalink / raw)
To: linux-kernel
On Saturday 28 October 2006 3:37 pm, Rob Landley wrote:
> Problem #2: statfs() and statvfs() are returning 0 in the f_fsid.
Which is apparently a known issue, the field has never worked and is useless,
and what you're supposed to do is a normal stat() on the sucker and and use
st_dev, which has been horribly abused to perform the function of uniquely
identifying things like tmpfs instances and /proc. :)
A fix to problem #1 would still be nice, but I can work around most of it...
Thanks,
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problems with /proc/mounts and statvfs (implementing df).
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
1 sibling, 1 reply; 4+ messages in thread
From: Ian Kent @ 2006-11-02 10:07 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel
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.
Current state of play can be found in files located at
http://www.kernel.org/pub/linux/daemons/autofs/v5.
Ian
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problems with /proc/mounts and statvfs (implementing df).
2006-11-02 10:07 ` Ian Kent
@ 2006-11-02 20:53 ` Rob Landley
0 siblings, 0 replies; 4+ messages in thread
From: Rob Landley @ 2006-11-02 20:53 UTC (permalink / raw)
To: Ian Kent; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-11-02 20:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox