Who needs these silly statfs changes...

Peter Edwards peter.edwards at openet-telecom.com
Fri Nov 14 12:10:11 PST 2003


Bruce Evans wrote:

> On Fri, 14 Nov 2003, Peter Edwards wrote:
>
>> Bernd Walter wrote:
>>
>>> On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
>>>
>>>
>>>> On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
>>>>
>>>>
>>>>> On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
>>>>>
>>>>>
>>>>>> ...my sparc machine reports that my i386 nfs server has 15 
>>>>>> exabytes of
>>>>>> free space!
>>>>>>
>>>>>> enigma# df -k
>>>>>> Filesystem 1K-blocks Used Avail Capacity Mounted on
>>>>>> rot13:/mnt2 56595176 54032286 18014398507517260 0% /rot13/mnt2
>>>>>>
>>>>>>
>>>>> 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it
>>>>> possible that rot13:/mnt2 has negative free space? (ie it's into the
>>>>> 8-10% reserved area).
>>>>>
>>>>>
>>>> Yes, that's precisely what it is..the bug is either in df or the
>>>> kernel (I suspect the latter, i.e. something in the nfs code).
>>>>
>>>>
>>> And it's nothing new - I'm seeing this since several years now.
>>>
>>>
>> The NFS protocols have unsigned fields where statfs has signed
>> equivalents: NFS can't represent negative available disk space ( Without
>> the knowledge of the underlying filesystem on the server, negative free
>> space is a little nonsensical anyway, I suppose)
>>
>> The attached patch stops the NFS server assigning negative values to
>> unsigned fields in the statfs response, and works against my local
>> solaris box. Seem reasonable?
>
>
> The client attampts to fix this by pretending that the unsigned fields
> are signed. -current tries to do more to support file system sizes larger
> that 1TB, but the code for this is not even wrong except it may be wrong
> enough to break the negative values. See my reply to one of the PRs
> for more details.
>
> I just got around to testing the patch in that reply:
>
> %%%
> Index: nfs_vfsops.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/nfsclient/nfs_vfsops.c,v


Your patch to nfs_vfsops won't apply to my Solaris kernel :-)
The protocol says "abytes" is unsigned, so the server shouldn't be lying 
by sending a huge positive value for available space on a full 
filesystem. No?



More information about the freebsd-current mailing list