Re: Who needs these silly statfs changes...

>On Fri, 14 Nov 2003, Peter Edwards wrote:
>
>> Bruce Evans wrote:
>>
>> > On Fri, 14 Nov 2003, Peter Edwards wrote:
>
>> >> 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:
>> > ...
>>
>> 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?
>
>Possibly not, but the protocol is broken if it actually requires that.

What makes you say that? I would think the utility of negative counts
for disk sizes and available spaces is marginal. Solaris, POSIX, and
NFS seem to get on fine without it. What am I (and they) missing?

>The "free" fields are signed in struct statfs so that they can be negative.
>However, this is broken in POSIX's struct statvfs (all count fields have
>type fsblkcnt_t or fsfilcnt_t and these are specified to be unsigned).
>Is Solaris bug for bug compatible with that?

I'm away from any solaris boxes at the moment, but I know that "df"
certainly reports huge free space when it sees the high bit set in 
the asize attribute of the NFS response. I'm not sure that this
is directly relevant to NFS, though. Whatever the operating system's
representation of FSSTATres is little to do with proper implementation
of the protocol. I've no idea what Win32 represents this data in, but
I'm sure it's very different from statv?fs. It'll provide and consume
NFS services, though.

>
>Anyway, my patch is mainly supposed to fix the scaling.  The main bug
>in the initial scaling patch was that the huge positive values were
>scaled before they were interpreted as negative values, so they became
>not so huge but still preposterous values that could not be interpreted
>as negative values.

Ok, Understood.

>
>The type pun to negative values is in most versions of BSD:
> [snip code snippets and bug]

That's great for interacting with other BSDs, but it still abusing
the protocol. As filesystems with approaching 2^64 bytes become possible
it probably has more of an impact.

I understand that this is proably not a big enough problem to break
historic behaviour for, of course.

>More changes are needed here to catch up with the recent changes to struct
>statfs in FreeBSD.  The casts to long are now just wrong since the block
>count fields don't have type long.

Sure.