Bug 164189 - nfs v3 client large disk df /statfs wrong result
nfs v3 client large disk df /statfs wrong result
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils (Show other bugs)
3.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-25 16:25 EDT by Mark Wiederspahn
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-17 08:32:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Wiederspahn 2005-07-25 16:25:15 EDT
Description of problem:
nfs mounts of solaris 8 disks larger than about 1G don't show correct size
if mounted vers=3. vers=2 mount shows correct size, as does
i686 vers=3. Disk of size 500G works fine. May be related to bugzilla 162259.

Version-Release number of selected component (if applicable):
nfs-utils-1.0.6-33EL, update 5 plus rhn to date.

How reproducible:
completely

Steps to Reproduce:
1.mount -o vers=3 sol8:/bigdisk /local
2.strace df -k /local/.
3.
  
Actual results:

statfs("/disk/other", {f_type="NFS_SUPER_MAGIC", f_bsize=18446744073709551615,
f_blocks=18446744073709551615, f_bfree=18446744073709551615,
f_bavail=18446744073709551615, f_files=18446744073709551615,
f_ffree=18446744073709551615, f_fsid={0, 0}, f_namelen=255, f_frsize=0}) = 0

Expected results:

same command on i686 machine, nfs-utils-1.0.6-33EL:

statfs64("/disk/other", 84, {f_type="NFS_SUPER_MAGIC", f_bsize=32768,
f_blocks=121891376, f_bfree=94671452, f_bavail=94671452, f_files=4294967295,
f_ffree=4294967295, f_fsid={0, 0}, f_namelen=255, f_frsize=0}) = 0
stat64("/disk/other", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

Additional info:

same command after mount -o vers=2 on x86_64:

statfs("/a", {f_type="NFS_SUPER_MAGIC", f_bsize=8192, f_blocks=487565504,
f_bfree=378298504, f_bavail=378298504, f_files=0, f_ffree=0, f_fsid={0, 0},
f_namelen=255, f_frsize=0}) = 0
stat("/a", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
Comment 1 Steve Dickson 2005-07-27 08:34:55 EDT
What kernel version are you using? If its the bug I'm thinking of
this as already been fixed in the U4 or U5 release
Comment 2 Steve Dickson 2005-07-27 08:37:38 EDT
I'm thinking that this is a dup of 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153094
Comment 3 Mark Wiederspahn 2005-07-27 09:31:14 EDT
#1 installed update 5 with redhat network updates as of yesterday.
rebooted to uname -a:
Linux amd2.ig.utexas.edu 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:46:36 EDT 
2005 x86_64 x86_64 x86_64 GNU/Linux

#2 I searched for nfs v3 and found only 162252 before I submitted a bug report
I can't access bug 153904 now with my bugzilla privileges. Maybe this is 
a "user new to bugzilla problem" - if so, apologies in advance, but I tried.
Comment 4 Steve Dickson 2005-07-27 11:52:18 EDT
I'm not sure why they the permission so tight in that bz, so
I put some nfs-utils in http://people.redhat.com/steved/rhel3/
which contain that patch from bz153094. Give it a try to see
if fixes this problem.... 
Comment 5 Mark Wiederspahn 2005-08-03 11:58:30 EDT
sorry to be so long getting back to you.
I guess I don't see where this is necessarily
an nfsutils problem if the statfs system call
returns bad data for v3 - I shouldn't have mentioned
nfs-utils, but I didn't then know how little of the
operational nfs code nfs-utils has in it.
Comment 6 Mark Wiederspahn 2005-08-10 14:54:08 EDT
This problem has been resolved, although I don't understand exactly how.

Some further information: the solaris 8 server filesystem was a Sun SAMfs
filesystem (version 4.2.8). When this server code was upgraded to 4.3.15,
apparently the df problem fixed itself. This wasn't noticed for a few days,
since there was no expectation that the server side had anything to do with it.
It may also be that the server was rebooted and it had nothing at all to do with
the SAMfs software upgrade.

now, strace df -k shows:

statfs("/disk/other", {f_type="NFS_SUPER_MAGIC", f_bsize=32768,
f_blocks=121891328, f_bfree=45927232, f_bavail=45927232, f_files=17776096,
f_ffree=17196352, f_fsid={0, 0}, f_namelen=255, f_frsize=0}) = 0


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