Re: Who needs these silly statfs changes...

(CC's trimmed, I'm sure I'm boring people at this stage.)
>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.

I just don't see how you can possibly infer from the NFS spec that
"abytes" is anything other than an unsigned quantity. I just think
assuming the client will interpret a massive value as probably
negative is a bit of a leap of faith. 

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

If the server tells the client that there are 2^64 - 1 bytes
remaining on the server, it's not second guessing anything by 
presenting that to the user.

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

(Note that NFS also gives a "fbytes", indicating the number of free
bytes, as opposed to "available to a particular user")

"bavail" can really only be worked out by the server. The server
is reserving a percentage for non-root user. The client can't work
out what that reserve percentage is.

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

Maybe we're talking across each other. That's my main point: the
server shouldn't put huge values in an unsigned field and
expect the client to interpret them in a way that the spec sets
no precedent for.

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

As far as implementing NFS is concerned, that's probably not
relevant: It doesn't have to be implemented in ISO C. The FreeBSD
compiler provides a 64-bit integer type that its implementation
is free to use :-)