Bug 84846 - df /disk2 accesses /disk1 as well
df /disk2 accesses /disk1 as well
Status: CLOSED UPSTREAM
Product: Red Hat Raw Hide
Classification: Retired
Component: coreutils (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-21 19:14 EST by Andrei Gaponenko
Modified: 2007-04-18 12:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-03-04 04:49:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Full strace of "/bin/df /twist/tw14" (5.75 KB, text/plain)
2003-02-21 19:17 EST, Andrei Gaponenko
no flags Details
Contents of /proc/mounts (2.63 KB, text/plain)
2003-02-21 19:18 EST, Andrei Gaponenko
no flags Details
Content of /etc/mtab (2.16 KB, text/plain)
2003-02-21 19:19 EST, Andrei Gaponenko
no flags Details

  None (edit)
Description Andrei Gaponenko 2003-02-21 19:14:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
The bug: "df /disk2" tries to access other filesystems as well.  

Why is this a bug?  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!

In our environment, a node can have dozens of nfs-mounted filesystems
from different servers, so the probability of getting into the trap is
not that small.  

I also tracked down a "user is not able to open an x-session" problem
to this df bug.  There is a "df $HOME" command in the KDE start-up
script, and the command blocked attempting to access a completely
irrelevant /dataXXX instead of reporting that there was plenty of
space on the user's home and letting him in.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Mount several disks and strace df on a disk from the middle of your
/etc/mtab.  This is an abbreviated version of what I got doing 
"df /twist/tw14" (a full strace, a copy of /etc/mtab and /proc/mounts are attached):

#================================================================
execve("/bin/df", ["/bin/df", "/twist/tw14"], [/* 40 vars */]) = 0
uname({sys="Linux", node="tw01.triumf.ca", ...}) = 0
brk(0)                                  = 0x804fe08

.....  # The usual shared lib clutter...

# Here it starts doing the job:

fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40013000
write(1, "Filesystem           1K-blocks  "..., 67) = 67
statfs("/twist/tw14", {f_type="NFS_SUPER_MAGIC", f_bsize=8192,
f_blocks=13667184, f_bfree=6449356, f_files=13893632, f_ffree=13887868,
f_namelen=255}) = 0

# What the heck is going on here???

open("/proc/mounts", O_RDONLY)          = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40014000
read(3, "rootfs / rootfs rw 0 0\n/dev/root"..., 4096) = 2694
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
.....
stat64("/home/e614data", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
stat64("/twist/tw01", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
stat64("/home/andr", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
stat64("/triumfcs/linux", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/twist/tw05z", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
stat64("/twist/tw06z", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
....
stat64("/twist/tw11", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/twist/tw12", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/twist/tw13", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/twist/tw14", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)                                = 0

# And here it finishes the job. Why not do this without stat()-ing the
# whole world?

write(1, "tw14:/data           109337472  "..., 68) = 68
munmap(0x40013000, 4096)                = 0
_exit(0)                                = ?
#================================================================


Actual Results:  df /disk2 stat()-s other disks as well. If some of them are not
accessible it blocks, even if /disk2 is OK.

Expected Results:  df /disk2 should print out info about /disk2 without
stat()-ing the whole world.

Additional info:

This is not a RH8 problem, but rather a pretty old one. I can see that df
behaves the same in RH6.2, for example.
Comment 1 Andrei Gaponenko 2003-02-21 19:17:25 EST
Created attachment 90270 [details]
Full strace of "/bin/df /twist/tw14"
Comment 2 Andrei Gaponenko 2003-02-21 19:18:21 EST
Created attachment 90271 [details]
Contents of /proc/mounts
Comment 3 Andrei Gaponenko 2003-02-21 19:19:26 EST
Created attachment 90272 [details]
Content of /etc/mtab
Comment 4 Tim Waugh 2003-03-03 12:38:50 EST
This seems to be due to getmntent, and still happens in coreutils.
Comment 5 Tim Waugh 2003-03-04 04:49:02 EST
Reported upstream as:
http://mail.gnu.org/archive/html/bug-coreutils/2003-03/msg00008.html

Note You need to log in before you can comment on or make changes to this bug.