/usr/bin/df reports false size on big NFS shares

/usr/bin/df reports false size on big NFS shares

[Samuel Maftoul]

On several machines, with kernel 2.4.18 the same mounts reports different
sizes than with 2.4.4 :

-------------------------------------------------------------------------
maftoul@brick20:~ > uname  -a 
Linux brick20 2.4.4-4GB #6 Thu Jul 26 10:00:30 CEST 2001 i686 unknown

maftoul@brick20:~ > df -h 
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13G  3.1G  9.5G  25% /
shmfs                 517M     0  516M   0% /dev/shm
grey:/disk91          230G  127G  102G  56% /mntdirect/_disk91
yellow:/disk23        140G  100G   39G  72% /mntdirect/_disk23
violet:/data/id19/external
                      2.7T  1.1T  1.6T  38% /mntdirect/_data_id19_external
maftoul@brick20:~ >
-------------------------------------------------------------------------

maftoul@brick4:~ > uname  -a 
Linux brick4 2.4.18 #3 Thu Apr 4 17:04:20 CEST 2002 i686 unknown
maftoul@brick4:~ > 

maftoul@brick4:~ > df -h 
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             4.7G  2.7G  2.0G  58% /
shmfs                 125M     0  124M   0% /dev/shm
grey:/disk91          230G  127G  102G  56% /mntdirect/_disk91
yellow:/disk23        140G  100G   39G  72% /mntdirect/_disk23
violet:/data/id19/external
                      669G -7.0Z  1.6T 101% /mntdirect/_data_id19_external
-------------------------------------------------------------------------

See the violet one ?
The reported size is the same on every 2.4.18 machine using this mount I
saw.

I have to say that these mounts are mounted via the automounter.

Bug ? or what ? 

It's all suse 7.2 , first one (2.4.4) is suse 7.2 base kernel, 2.4.18 is
our own (for firewire better firewire support).


If I send this mail to the wrong place ( which I doubt ) please, say it
so I'll try to report somewhere else.

Thanks 
        Samuel 

Re: /usr/bin/df reports false size on big NFS shares

[Andreas Dilger]

On Jun 10, 2002  16:54 +0200, Samuel Maftoul wrote:
> On several machines, with kernel 2.4.18 the same mounts reports different
> sizes than with 2.4.4 :
> 
> -------------------------------------------------------------------------
> maftoul@brick20:~ > uname  -a 
> Linux brick20 2.4.4-4GB #6 Thu Jul 26 10:00:30 CEST 2001 i686 unknown
> 
> maftoul@brick20:~ > df -h 
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sda1              13G  3.1G  9.5G  25% /
> shmfs                 517M     0  516M   0% /dev/shm
> grey:/disk91          230G  127G  102G  56% /mntdirect/_disk91
> yellow:/disk23        140G  100G   39G  72% /mntdirect/_disk23
> violet:/data/id19/external
>                       2.7T  1.1T  1.6T  38% /mntdirect/_data_id19_external
> maftoul@brick20:~ >
> -------------------------------------------------------------------------
> 
> maftoul@brick4:~ > uname  -a 
> Linux brick4 2.4.18 #3 Thu Apr 4 17:04:20 CEST 2002 i686 unknown
> maftoul@brick4:~ > 
> 
> maftoul@brick4:~ > df -h 
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sda1             4.7G  2.7G  2.0G  58% /
> shmfs                 125M     0  124M   0% /dev/shm
> grey:/disk91          230G  127G  102G  56% /mntdirect/_disk91
> yellow:/disk23        140G  100G   39G  72% /mntdirect/_disk23
> violet:/data/id19/external
>                       669G -7.0Z  1.6T 101% /mntdirect/_data_id19_external
> -------------------------------------------------------------------------
> 
> See the violet one ?
> The reported size is the same on every 2.4.18 machine using this mount I
> saw.

Probably an overflow in the math somewhere.  Since the overflow is in
the zettabyte range, it is probably someone not being careful with
64-bit values overflowing.  "64-bit values are large enough for
everything, right..."

> It's all suse 7.2 , first one (2.4.4) is suse 7.2 base kernel, 2.4.18 is
> our own (for firewire better firewire support).

Probably the best thing you can do is either diff the two kernel sources
looking for changes in fs/nfs, or start with 2.4.4 and apply patches
until you get a failure.

I don't think a lot of people will be able to help you test this, as
they don't have 2.7TB NFS servers available ;-).

Cheers, Andreas

FYI: In case anyone is wondering (I was) a "Z" is a Zettabyte (2^70 bytes).
     It falls between Exabyte (1024 PB = 2^60) and Yottabyte (2^80).
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: /usr/bin/df reports false size on big NFS shares

[Samuel Maftoul]

On Mon, Jun 10, 2002 at 02:39:13PM -0400, Hank Leininger wrote:
> Most distributions ship slightly (or heavily) patched kernels.  Above you
> can see the 2.4.4 kernel is not stock, it is named '2.4.4-4GB' for one
> thing, which most likely means it is tweaked for a 4GB memory system?  That
> may be how SuSE shipped kernels for 7.2, idunno.  But the point is, it is
> likely that stock 2.4.4 would not work either, it would have the same
> problem as 2.4.18.  There's some added bits in  SuSE's release kernel that
> make >1TB NFS shares happy.  I'd suggest that you try booting 2.4.4 stock
I'm using 2.4.18 unofficial srpm from suse ftp server, we need this
because we have hudge needs ( scientific research institute).
I think mostly the same patche are applied.
I'll try to find a "pirate" RH system (we don't support it) at work and
see if the same behavious applies.
> just to see if it misbehaves the same way 2.4.18 does, and if so, start
> trying to figure out what SuSE patch fixes this for you (check SuSE
> specific lists, and/or ask their support).  With luck you will find that
> either SuSE has a newer 2.4.x kernel with firewire support, or whatever
That's the point, their unofficial rpm's has it.
> they've done that fixes NFS can be extracted out and added to a current
> stock 2.4.x kernel source.
That probably won't be the case. :)
> --
> Hank Leininger <hlein@progressive-comp.com> 
        Sam

Re: /usr/bin/df reports false size on big NFS shares

[Hank Leininger]

On 2002-06-10, Samuel Maftoul <maftoul@esrf.fr> wrote:

> On several machines, with kernel 2.4.18 the same mounts reports
> different sizes than with 2.4.4 :

...Or not.

> - maftoul@brick20:~ > uname  -a
> Linux brick20 2.4.4-4GB #6 Thu Jul 26 10:00:30 CEST 2001 i686 unknown
[works]

> maftoul@brick4:~ > uname  -a
> Linux brick4 2.4.18 #3 Thu Apr 4 17:04:20 CEST 2002 i686 unknown
[doesn't work]

> It's all suse 7.2 , first one (2.4.4) is suse 7.2 base kernel, 2.4.18
> is our own (for firewire better firewire support).

Most distributions ship slightly (or heavily) patched kernels.  Above you
can see the 2.4.4 kernel is not stock, it is named '2.4.4-4GB' for one
thing, which most likely means it is tweaked for a 4GB memory system?  That
may be how SuSE shipped kernels for 7.2, idunno.  But the point is, it is
likely that stock 2.4.4 would not work either, it would have the same
problem as 2.4.18.  There's some added bits in  SuSE's release kernel that
make >1TB NFS shares happy.  I'd suggest that you try booting 2.4.4 stock
just to see if it misbehaves the same way 2.4.18 does, and if so, start
trying to figure out what SuSE patch fixes this for you (check SuSE
specific lists, and/or ask their support).  With luck you will find that
either SuSE has a newer 2.4.x kernel with firewire support, or whatever
they've done that fixes NFS can be extracted out and added to a current
stock 2.4.x kernel source.

--
Hank Leininger <hlein@progressive-comp.com>