NFS has a file size overflow problem

[Neal Lippman <nl@lippman.org>]

I don't know if this is known or not known, so I am throwing it out here
first to see if anyone has heard of this one before. My guess is this is
a known problem...

I use nfs to share my /home and a /shared directory on my fileserver to
workstations. The fileserver runs testing and is up to date. The
workstation was just upgraded to unstable.

As a backup mechanism, on the server, I tar up my whole directory tree,
split it into 600 MB files and burn to cds. I figure in the event of
catastrophe, just copy the cd files back to hard disk, cat them
together, and untar.

So, I backup via:
	tar zcf /shared/backup/hometar; split -b 600m hometar
then take each split file for burning to cd.

Anyway, that's all beside the point except to explain how I wound up
with a file that's about 5.5 GB. So, I do ls -l in the backup directory
and in one xterm the file size is 5.5 GB, and in the other it's around
1.3 GB. So, what gives? Further, the split which divides up into 600MB
files generates the expected number (around 9) of subfiles, so I know
the actual size must be around 5.5 GB.

Then, I realize that if NFS reports the file size in a 32bit entity,
then subtracting the 4 GB or so you can get in 32 bits, the overflow is
around the difference, around 1.3 GB or so. AND, I see the correct 5.5
GB in the xterm that is ssh'd over to the server and therefore NOT
getting info via nfs, while the incorrectly small amount is in an xterm
logged in to the workstation.

So I'm thinking maybe nfs is stuffing a 64 bit file size on the server
into a 32 bit filesize in the info it sends to the workstation.

Here's the weird thing, though: I tried wc hometar in both the xterm on
the server and the one one on the workstation - and they both give the
same results that ls -l showed, eg running wc on the workstation gives
the same incorrect 1.3 GB character count. Now, I would have guessed
that wc worked by reading chars until EOF - so you'd figure it would get
the correct 5.5GB answer. I'm further guessing, however, that the
filesystem, after stat'ing a file, knows how large it is and doesn't let
you read off the end of the file and generates the EOF without having to
ask the server for data that exists but which the NFS client thinks is
beyond the end of the file.

So: presumably NFS is known to use 32 bit file sizes, but ls understands
a 64 bit file size? I also note that the fstat, stat etc system calls
return the file size as an off_t, which in the i86 header files for
2.4.22 is a long - which should be 32 bits on x86- so how does ls -l get
the correct >32bit file size?

nl