Re: Who needs these silly statfs changes...

Peter Edwards 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!

[ ... ]

> 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?

I disagree.

The intent of the negative number from df is to subtract the amount
used from the total amount available, in order to get the amount
remaining.

When this results in a negative number, what it's saying is that
you are using up space from the free reserve.

This is an artifact of implementation on the server, and should
not be second-guessed by the client.

The problem in this case is on the client, not the server, in not
doing the conversion as an unsigned operation.  The place for the
subtraction to occur is in the "df" program.  In other words, the
statfs->f_bavail should be recalculated locally from the values
of statfs->f_blocks and statfs->f_bfree, not used directly out of
the (unsigned) NFS values... or the values should be converted to
signed values coming out of NFS prior to their sign extension to
the size type.


On a slightly related note, the standards mandated interfaces say
that the values should be fsblkcnt_t, which must be an unsigned
integer type.  This coordinates well with my point of the sign
conversion on legacy interface needing to happen at presentation
time.

Also, if you read the ISO C99 standard, you'll see that on an
ILP32 system, there is no way to legitimately define an integer
type in excess of 32 bits, unless long is larger than 32 bits
(see section 3.6), so defining these things as 64 bits without
compiler changes is wrong anyway.

-- Terry