Bug 121273 - With 2.6.4-1.300, "df" says "Value too large for defined data type"
Summary: With 2.6.4-1.300, "df" says "Value too large for defined data type"
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils   
(Show other bugs)
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-19 22:16 UTC by Konstantin Olchanski
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-19 16:47:34 UTC
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 18:30 UTC, Konstantin Olchanski
no flags Details

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.


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

How reproducible:

Steps to Reproduce:
1. blah...

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.

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