Bug 121273

Summary: With 2.6.4-1.300, "df" says "Value too large for defined data type"
Product: [Fedora] Fedora Reporter: Konstantin Olchanski <olchansk>
Component: coreutilsAssignee: Arjan van de Ven <arjanv>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-06-19 16:47:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace df /home/olchansk none

Description Konstantin Olchanski 2004-04-19 22:16:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Description of problem:
"df" in Fedora1 with the kernel-smp-2.6.4-1.300 kernel does not work
for some NFS filesystems:

[olchansk@jam olchansk]$ df /home/olchansk
Filesystem           1K-blocks      Used Available Use% Mounted on
df: `/home/olchansk': Value too large for defined data type

[olchansk@jam olchansk]$ grep olch /proc/mounts 
sam:/home1/olchansk /home/olchansk nfs
rw,v3,rsize=8192,wsize=8192,hard,intr,udp,lock,addr=sam 0 0

On the NFS server:

[olchansk@sam olchansk]$ df /home/olchansk
Filesystem           1K-blocks      Used Available Use% Mounted on
/home1/olchansk       30715336  27196188   3519148  89% /home/olchansk

[olchansk@sam olchansk]$ grep home1 /proc/mounts 
/dev/hda2 /home1 reiserfs rw 0 0

This is probably a mismatch between the 2.6 kernel and "df" or
"glibc", but I do not see it reported anywhere. It could be specific
to NFS mouting reiserfs filesystems, too.

K.O.


Version-Release number of selected component (if applicable):
kernel-smp-2.6.4-1.300

How reproducible:
Always

Steps to Reproduce:
1. blah...
2.
3.
    

Additional info:

Comment 1 Tim Waugh 2004-04-20 16:56:35 UTC
What does 'strace df /home/olchansk' say?  It's not clear to me where
this error originates.

Comment 2 Konstantin Olchanski 2004-04-20 18:30:31 UTC
Created attachment 99571 [details]
strace df /home/olchansk

Comment 3 Konstantin Olchanski 2004-04-20 18:31:34 UTC
The error is coming from "statfs("/home/olchansk", 0xfeeb4fd4)    = -1
EOVERFLOW (Value too large for defined data type)". The full strace is
attached. K.O.



Comment 4 Tim Waugh 2004-04-20 18:41:20 UTC
Not sure that df can really rely on any of the values then.  Looks to
me like reporting an error is all it can do.

I wonder why statfs() returns that in the first place.

Comment 5 Konstantin Olchanski 2004-06-19 02:56:07 UTC
So if the problem is in "statfs", reassign the bug to the statfs
bozos,  but please don't just close the bug and hope the problem or I
will go away. K.O.


Comment 6 Dave Jones 2004-06-19 16:47:34 UTC
there's not really anything that can be done to fix this that I can see.
your glibc is compiled against 2.4 kernel headers. That struct changed
in 2.6, so unsurprisingly, glibc gets confused and returns nonsense,
which the app then tries to translate.

the only answer I see is to use a glibc compiled against 2.6 headers.

remember also, that FC1 never shipped with a 2.6 kernel, and as such
lots of userspace isn't prepared for it. It's completely unsurprisingly
that some things break.