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 - df /disk2 accesses /disk1 as well
Summary: df /disk2 accesses /disk1 as well
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: coreutils
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-22 00:14 UTC by Andrei Gaponenko
Modified: 2007-04-18 16:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-03-04 09:49:02 UTC


Attachments (Terms of Use)
Full strace of "/bin/df /twist/tw14" (deleted)
2003-02-22 00:17 UTC, Andrei Gaponenko
no flags Details
Contents of /proc/mounts (deleted)
2003-02-22 00:18 UTC, Andrei Gaponenko
no flags Details
Content of /etc/mtab (deleted)
2003-02-22 00:19 UTC, Andrei Gaponenko
no flags Details

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


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