Re: df enhancment for removable media
Kevin R. Bulgrien [EMAIL PROTECTED] writes: Did anything final every come out of this thread. Not from the coreutils side, no. My assumption is that it's some sort of low-level system bug. But we haven't heard from the low-level guys (whom you probably should be talking to). The simple ls /media/USB_DISK /dev/null; df /media/USB_DISK example is not sufficient to get df to report something real. How about ls /media/USB_DISK/no/such/file /dev/null 21? The idea is to ask a question of the file system that requires that it actually be mounted. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
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. Thanks, 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/sda10 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 252522238718 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. thanks, Jw. Paul Eggert wrote: Juergen Weigert [EMAIL PROTECTED] 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
Paul Eggert wrote: Juergen Weigert [EMAIL PROTECTED] 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. Did this ever come to anything. I have a bash script plug-in for a KDE application that is hosed on Suse 10 something or another because df is not reporting the free space on a mounted USB device. Is there a practical and reliable work-around for a shell script? Not sure what questions to ask. I never heard of df doing this before, though now I see it is apparently not df per se. What is a shell script to do? Thanks, Kevin R. Bulgrien ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
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. Thanks, 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/sda10 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 252522238718 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. thanks, Jw. Paul Eggert wrote: Juergen Weigert [EMAIL PROTECTED] 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
Phillip Susi wrote: 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. It's not my system, and as an author of a script used by a lot of people, I don't have a choice about how the system is configured, but my script has to work anyway. In this case I do not think it is autofs. The example given was from a previous post. df does not report a mounted directory in the case I am thinking of. This was unheard of for me because the script specifically mounted the disk. I didn't say this was a df bug, but I did ask if anything came of the discussion about working on statfs so that on Suse systems like this, the df command would do enough so that hal (or whoever) would properly mount the media enough to get a valid df reading. Last I could see on the thread, nobody was disputing that this would be a good thing. 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. Sorry, but its just plain weird to have a system dismount media that you explicitly mounted. All I am looking for is an idea of the most sane way to script something so I can get what I want from df on a system that is configured like the Suse systems that spawned the thread in the first place. I just have not encountered this type of situation before. Kevin R. Bulgrien ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Juergen Weigert on 9/20/2005 2:54 PM: Wouldn't open() suffice? That would be simpler. I chose opendir(), because I am not sure if all systems allow open() on a directory node. Otherwise I'd also favour open(), it has no issue with getting a header file for dirent/direct, or whatever the directory structure may be called. POSIX requires open() to work on directories, and GNU find has been using open() and not opendir() for some time now (although with the recent switch in find to use gnulib's fts module, that will change in find 4.3.x.) The only bug that I am aware of that was reported to find where open(dir) failed was due to a cygwin bug which has since been fixed in cygwin. If, in fact, we do find a non-compliant system where open() fails on dirs, it might be better if that system were given a gnulib module that implemented a wrapper around open which calls stat then open/opendir as needed, rather than penalizing the majority of compliant systems. Sure. Is it sufficient to abondon copyright, Nope - FSF requires assignment of copyright, not abandonment. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMVFO84KuGfSFAYARArbWAJ4u5vf2mb2m41Xf4PXKUmrcl4vpkgCgiHLy XtODojf1rUFqFXGe6gw8bUA= =69ER -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
Sure. Is it sufficient to abondon copyright, Nope - FSF requires assignment of copyright, not abandonment. This is not true. But one must do so in writting (i.e. signing a copyright disclaimer, which more or less puts the changes/program into the Public Domain). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
Juergen Weigert [EMAIL PROTECTED] 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
Juergen Weigert [EMAIL PROTECTED] writes: 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/sda10 0 0 - /media/USB_DISK only if the USB_DISK is being accessed, I get the expected output. Thanks for reporting the issue. 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. Wouldn't open() suffice? That would be simpler. 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. Also, the main fix needs to be in fsusage.c, not df.c. If the new option is in effect, fsusage.c should attempt to open() the file, then use fstatfs on the result; it should fall back on statfs if the open fails. This will require a new boolean option to get_fs_usage, which asks it to use open/fstatfs rather than statfs (and similarly for the other hosts, e.g., use fstatvfs rather than statvfs). Finally, we'd need copyright papers from you to accept such a patch; I assume this is OK? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
On Sep 20, 05 13:12:46 -0700, Paul Eggert wrote: Juergen Weigert [EMAIL PROTECTED] writes: 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/sda10 0 0 - /media/USB_DISK only if the USB_DISK is being accessed, I get the expected output. Thanks for reporting the issue. 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. Wouldn't open() suffice? That would be simpler. I chose opendir(), because I am not sure if all systems allow open() on a directory node. Otherwise I'd also favour open(), it has no issue with getting a header file for dirent/direct, or whatever the directory structure may be called. 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. Also, the main fix needs to be in fsusage.c, not df.c. If the new option is in effect, fsusage.c should attempt to open() the file, then use fstatfs on the result; it should fall back on statfs if the open fails. Looks ugly in df.c, right. But in fsusage.c we'd have to place the new code in multiple implementations. Ugly too. This will require a new boolean option to get_fs_usage, which asks it to use open/fstatfs rather than statfs (and similarly for the other hosts, e.g., use fstatvfs rather than statvfs). Finally, we'd need copyright papers from you to accept such a patch; I assume this is OK? Sure. Is it sufficient to abondon copyright, or do you want to have it? thanks, Jw. -- o \ Juergen Weigert paint it green! __/ _===.===_ V | [EMAIL PROTECTED] wide open suse_/_---|\/ \ | 0911 74053-508 (tm)__/ (//\ (/) | __/ _/ \_ vim:set sw=2 wm=8 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
df enhancment for removable media
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/sda10 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 252522238718 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.
thanks,
Jw.
--
o \ Juergen Weigert paint it green! __/ _===.===_
V | [EMAIL PROTECTED] wide open suse_/_---|\/
\ | 0911 74053-508 (tm)__/ (//\
(/) | __/ _/ \_ vim:set sw=2 wm=8
--- ./doc/coreutils.texi.orig 2005-09-17 09:44:42.0 +0200
+++ ./doc/coreutils.texi2005-09-19 19:08:54.528587971 +0200
@@ -8763,6 +8763,16 @@
Limit the listing to local file systems. By default, remote file systems
are also listed.
[EMAIL PROTECTED] -n
[EMAIL PROTECTED] --no-mount
[EMAIL PROTECTED] -n
[EMAIL PROTECTED] --no-mount
[EMAIL PROTECTED] file system space, retriving output from removable media
+Per default, a mountpoint that reports 0 blocks, will be opended via
@code{opendir}
+and a second attempt will be made to report the stats. This trick usually
monts the
+device, if it is a removable media.
+This option prevents this mount attempt and reports 0 blocks in that case.
+
@item --no-sync
@opindex --no-sync
@cindex file system space, retrieving old data more quickly
--- ./src/df.c.orig 2005-08-16 22:33:40.0 +0200
+++ ./src/df.c 2005-09-19 19:08:05.492105049 +0200
@@ -24,6 +24,7 @@
#include sys/types.h
#include getopt.h
#include assert.h
+#include dirent.h
#include system.h
#include canonicalize.h
@@ -69,6 +70,9 @@
/* If true, use the POSIX output format. */
static bool posix_format;
+/* If true, use opendir to attempt a mount if blocks would be 0. */
+static bool no_mount_attempt;
+
/* If true, invoke the `sync' system call before getting any usage data.
Using this option can make df very slow, especially with many or very
busy disks. Note that this may make a difference on some systems --
@@ -128,6 +132,7 @@
{kilobytes, no_argument, NULL, 'k'}, /* long form is obsolescent */
{local, no_argument, NULL, 'l'},
{megabytes, no_argument, NULL, 'm'}, /* obsolescent */
+ {no-mount, no_argument, NULL, 'n'},
{portability, no_argument, NULL, 'P'},
{print-type, no_argument, NULL, 'T'},
{sync, no_argument, NULL, SYNC_OPTION},
@@ -305,6 +310,20 @@
return;
}
+ if (!no_mount_attempt fsu.fsu_blocks == 0)
+{
+ DIR *d = NULL;
+ d = opendir(stat_file);
+ if (get_fs_usage (stat_file, disk, fsu))
+{
+ if (d) closedir(d);
+ error (0, errno, %s, quote (stat_file));
+ exit_status = EXIT_FAILURE;
+ return;
+}
+ if (d) closedir(d);
+}
+
if (fsu.fsu_blocks == 0 !show_all_fs !show_listed_fs)
return;
@@ -732,6 +751,7 @@
-klike --block-size=1K\n\
-l, --local limit listing to local file systems\n\
--no-sync do not invoke sync before getting usage info
(default)\n\
+ -n, --no-mountdo not attempt to mount removable media\n\
), stdout);
fputs (_(\
-P, --portability use the POSIX output format\n\
@@ -772,6 +792,7 @@
inode_format = false;
show_all_fs = false;
show_listed_fs = false;
+ no_mount_attempt = false;
human_output_opts = human_options (getenv (DF_BLOCK_SIZE), false,
output_block_size);
@@ -780,7 +801,7 @@
posix_format = false;
exit_status = EXIT_SUCCESS;
- while ((c = getopt_long (argc, argv, aB:iF:hHklmPTt:vx:, long_options,
NULL))
+ while ((c = getopt_long (argc, argv, aB:iF:hHklmnPTt:vx:, long_options,
NULL))
!= -1)
{
switch (c)
@@ -813,6 +834,9 @@
human_output_opts = 0;
output_block_size = 1024 * 1024;
break;
+ case 'n':
+ no_mount_attempt = true;
+ break;
case 'T':
print_type = true;
break;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
