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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"