Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 84846

Summary: df /disk2 accesses /disk1 as well
Product: [Retired] Red Hat Raw Hide Reporter: Andrei Gaponenko <andr>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED UPSTREAM QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: george.liu, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-03-04 09:49:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Full strace of "/bin/df /twist/tw14"
none
Contents of /proc/mounts
none
Content of /etc/mtab none

Description Andrei Gaponenko 2003-02-22 00:14:40 UTC
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-22 00:17:25 UTC
Created attachment 90270 [details]
Full strace of "/bin/df /twist/tw14"

Comment 2 Andrei Gaponenko 2003-02-22 00:18:21 UTC
Created attachment 90271 [details]
Contents of /proc/mounts

Comment 3 Andrei Gaponenko 2003-02-22 00:19:26 UTC
Created attachment 90272 [details]
Content of /etc/mtab

Comment 4 Tim Waugh 2003-03-03 17:38:50 UTC
This seems to be due to getmntent, and still happens in coreutils.

Comment 5 Tim Waugh 2003-03-04 09:49:02 UTC
Reported upstream as:
http://mail.gnu.org/archive/html/bug-coreutils/2003-03/msg00008.html