bug-glibc
[Top][All Lists]
Advanced

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

Re: df /mnt/foo and getmntent


From: Jim Meyering
Subject: Re: df /mnt/foo and getmntent
Date: Tue, 04 Mar 2003 09:58:42 +0100

Tim Waugh <address@hidden> wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84846
>
> The df(1) from coreutils 4.5.3 uses getmntent on Linux, and this seems
> to cause the problem noted in the above bug report, namely:
>
> "Imagine that /disk1 is NFS mounted (hard), and server1 is down.
>  Server2, at the same time, is OK, and /disk2 is in fact available. I
>  want to do my work on /disk2. But "df /disk2" blocks waiting for
>  server1!  I don't need /disk1, and I don't want to know anything
>  about it!"

Thanks for forwarding that!

> Is there any way around this?

The problem is that glibc's statvfs performs all of those `stat' calls.
See libc/sysdeps/unix/sysv/linux/statvfs/internal_statvfs.c.
It could be optimized for this case -- just perform string comparisons
first -- thus saving all of those stat calls, when the given FILE is
a mount point.

Luckily, coreutils can work around the problem.
I've changed the autoconf test so that check for a working statvfs
function fails on a system with GNU libc.  In that case, we fall back
on statfs, which works just fine.

Here's the patch:

        `df /some/mount-point' no longer hangs when an unrelated hard-mount
        is unavailable
        * fsusage.m4 [__GLIBC__]: GNU libc's statvfs stats each mount point in
        /proc/mounts until it finds one with matching device number.  This is
        unnecessary when the FILE argument *is* a mount point.  No stat call
        is necessary in that case.  So, disable the statvfs-testing code on
        systems with GNU libc.  Reported by Andrei Gaponenko via Tim Waugh
        as RedHat bug# 84846.

Note that this change is not in the spirit of autoconf.
Ideally, I'd write a run-time test that would reject using
statvfs only if it exhibits the offending behavior.  Then if/when
it is fixed in libc, the fixed statvfs would once again be used.
However, run-time tests are frowned upon (makes cross-compiling
harder) and detecting the condition looks like it'd be tricky.

Index: m4/fsusage.m4
===================================================================
RCS file: /fetish/cu/m4/fsusage.m4,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 fsusage.m4
--- m4/fsusage.m4       12 Aug 2001 13:26:00 -0000      1.14
+++ m4/fsusage.m4       4 Mar 2003 08:40:47 -0000
@@ -1,4 +1,4 @@
-#serial 8
+#serial 9
 
 # From fileutils/configure.in
 
@@ -24,6 +24,11 @@ if test $ac_fsusage_space = no; then
   # SVR4
   AC_CACHE_CHECK([for statvfs function (SVR4)], fu_cv_sys_stat_statvfs,
                 [AC_TRY_LINK([#include <sys/types.h>
+#ifdef __GLIBC__
+Do not use statvfs on systems with GNU libc, because that function stats
+all preceding entries in /proc/mounts, and that makes df hang if even
+one of the corresponding file systems is hard-mounted, but not available.
+#endif
 #include <sys/statvfs.h>],
                              [struct statvfs fsd; statvfs (0, &fsd);],
                              fu_cv_sys_stat_statvfs=yes,




reply via email to

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