public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 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