Re: Who needs these silly statfs changes...

From: Bruce Evans <bde_at_zeta.org.au>
Date: Sun, 16 Nov 2003 12:54:57 +1100 (EST)
On Fri, 14 Nov 2003 peter.edwards_at_openet-telecom.com wrote:

> >> Bruce Evans wrote:
> >> > ...
> >> > 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?

Well, the f_bavail field (not to mention all the other fields (until
recently, sigh)) has always been signed and does go negative in BSD's
statfs, so the protocol is broken if it can't support negative values
in it.

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

2^63 won't be needed any time soon.  This problem was more serious with
nfsv2 when file systems reached 2^31 bytes not so long ago.

The current problem is actually more with non-BSD clients and a BSD server.
The BSD server will send the negative values and the non-BSD client may
convert them to huge positive ones.  Non-BSD servers presumably won't send
negative values.

Bruce
Received on Sat Nov 15 2003 - 16:55:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:29 UTC