[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: df enhancment for removable media

From: Phillip Susi
Subject: Re: df enhancment for removable media
Date: Tue, 21 Mar 2006 23:00:36 -0500
User-agent: Mail/News 1.5 (X11/20060309)

This sounds like an autofs problem. I'm running ubuntu and hal auto mounts removable media when it is inserted. When it is not mounted, df will not show a line for it at all, since df only shows mounted points. I think what you are seeing is an autofs mount point being mounted there which is why df shows a line for the mount point, but autofs has decided to unmount the real fs and return bogus stat values.

I'd suggest not using autofs.  In any case, this isn't a bug with df.

Kevin R. Bulgrien wrote:
Did anything final every come out of this thread.  I've written a
plug-in script for amaroK that a Suse user is complaining about.
I never heard of a system unmounting a disk automagically behind
the user's back when a mount was explicitly requested.

df is reporting USB media to be have 0 bytes free.  The simple
ls /media/USB_DISK >/dev/null; df /media/USB_DISK example is not
sufficient to get df to report something real.

Does anyone feel like giving some idea how this might best be
handled.  I hate to kludge things by creating a file on the USB
device, and it seems silly to over-access the media just to get
a df to output what I want.  I could do a find, because some
other function in my script does that and df reports properly,
but it seems pretty heavy-handed for a simple space check to
run through a USB drive that might be a few GB in size with
hundreds of files.

Is this something that was "fixed" so that a later version of
Suse might have a df that works?  If so, I might just allow the
user to override the space checking in the event he has an
affected system.


Kevin R. Bulgrien

Juergen Weigert wrote:

Hi coreutils people!

On a recent SUSE Linux df became unreliable for e.g. USB-drives.
This is because hald automatically mounts and unmounts such drives
as they are accessed.

Usually I get something like:

$ df /media/USB_DISK
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1                    0         0         0   -  /media/USB_DISK

only if the USB_DISK is being accessed, I get the expected output.

$ ls /media/USB_DISK > /dev/null; df /media/USB_DISK
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1               252522    238718     13804  95% /media/USB_DISK

A simple enhancement for df is to actively access the USB_DISK while
running statfs(). I've added an opendir() call in the attached patch. This
can be suppressed with a new commandline option -n.

Please keep me in CC, I am not subscribed.


Paul Eggert wrote:

Juergen Weigert <address@hidden> writes:

Unless I'm missing something I'd rather not change the default behavor
of df, as that would be a compatibility hassle.  That is, df shouldn't
attempt to mount file systems by default; it should do so only if the
user asks, with a new option.
These hald mounts are different. For almost every aspect such a device
appears to be mounted. So I figured, df should also pretend the
device is mounted.
But lots of programs other than df invoke statfs.  We shouldn't have
to change them all.  Instead, it would be much better to fix statfs to
do the right thing with hald mounts.  statfs should return values that
are consistent with every other system call: it should not return
incorrect values simply for the convenience of some low-level hardware
abstraction layer.

Please also see the message from Ivan Guyrdiev of Cornell archived at
<http://www.nsa.gov/selinux/list-archive/0507/thread_body36.cfm> dated
2005-07-20 in which he says something similar: the statfs
implementation needs to get fixed.

Looks ugly in df.c, right. But in fsusage.c we'd have to place the
new code in multiple implementations. Ugly too.
It would only need to be placed in sections corresponding to
implementations that have the bug.  Currently, that's just one
implementation: GNU/Linux, and only a small subset of these hosts as
well.  Since the workaround issues more system calls, it would be nice
to detect the broken implementations at compile-time somehow, or at
least filter out the obviously non-broken implementations.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]