Bug 67178 - df -l stat64's non-local filesystems
Summary: df -l stat64's non-local filesystems
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: wdovlrrw
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-20 17:40 UTC by Erik Kline
Modified: 2007-04-18 16:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-29 23:26:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Erik Kline 2002-06-20 17:40:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; H010818)

Description of problem:
RedHat 7.3, fileutils-4.1-10, strace of df -l shows that it stat64's all 
filesystems in the mtab and then attempts to print just the local 
filesystems. This hangs if there's an NFS mount hang. df -l should only stat 
local filesystems period. Bad algorithm!

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


How reproducible:
Always

Steps to Reproduce:
1.mount NFS partition
2.strace df -kl
3.watch output for stat64(NFS-partition)

If you disconnect the NFS server and re-run df -kl you'll see that it hangs.

Actual Results:  If the NFS server is down in any way then df -l hangs. strace 
output reveals that df -l stats everything in the mtab and then prints only the 
local filesystems.

Expected Results:  What should happen, algorithmically is that df -l should run 
through the mtab and only stat (and then print) local filesystems. This is the 
correct behaviour and many things break because this behaviour changed.

Additional info:

Comment 1 Erik Kline 2002-07-01 16:02:28 UTC
any progress? has anyone even looked at this to decide what to do (if anything) 
about it?

Comment 2 Bernhard Rosenkraenzer 2002-08-29 23:26:37 UTC
This is fixed in 4.1.9-*.

[root@aachen root]# df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1             38337872  36399588   1938284  95% /
none                    256200         0    256200   0% /dev/shm
none                    256200         0    256200   0% /build/ark-1.0/dev/shm
172.16.2.140:/mnt/raid
                     310130136 309228232    901904 100% /mnt/raid
172.16.2.140:/mnt/stgt
                     179413064  81773888  97639176  46% /mnt/stgt
[root@aachen root]# strace df -k 2>&1 |grep stgt
statfs("/mnt/stgt", {f_type="NFS_SUPER_MAGIC", f_bsize=8192, f_blocks=22426633,
f_bfree=12204897, f_files=5632000, f_ffree=5136554, f_namelen=255}) = 0
stat64("/mnt/stgt", {st_mode=S_IFDIR|S_ISUID|0755, st_size=4096, ...}) = 0
stat64("/mnt/stgt", {st_mode=S_IFDIR|S_ISUID|0755, st_size=4096, ...}) = 0
172.16.2.140:/mnt/stgt
                     179413064  81773888  97639176  46% /mnt/stgt
[root@aachen root]# strace df -kl 2>&1 |grep stgt
[root@aachen root]#



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