Bug 121273 - With 2.6.4-1.300, "df" says "Value too large for defined data type"
With 2.6.4-1.300, "df" says "Value too large for defined data type"
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-04-19 18:16 EDT by Konstantin Olchanski
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-19 12:47:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace df /home/olchansk (2.53 KB, text/plain)
2004-04-20 14:30 EDT, Konstantin Olchanski
no flags Details

  None (edit)
Description Konstantin Olchanski 2004-04-19 18:16:19 EDT
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.


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

How reproducible:

Steps to Reproduce:
1. blah...

Additional info:
Comment 1 Tim Waugh 2004-04-20 12:56:35 EDT
What does 'strace df /home/olchansk' say?  It's not clear to me where
this error originates.
Comment 2 Konstantin Olchanski 2004-04-20 14:30:31 EDT
Created attachment 99571 [details]
strace df /home/olchansk
Comment 3 Konstantin Olchanski 2004-04-20 14:31:34 EDT
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 14:41:20 EDT
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-18 22:56:07 EDT
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 12:47:34 EDT
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.

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