Date: Sun, 1 May 2011 16:43:29 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Bruce Evans <brde@optusnet.com.au> Cc: rmacklem@freebsd.org, fs@freebsd.org Subject: Re: newnfs client and statfs Message-ID: <135141673.835577.1304282609097.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110502022441.H2013@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, 1 May 2011, Rick Macklem wrote: > > >> > >> % + sbp->f_blocks = sfp->sf_tbytes / NFS_FABLKSIZE; > >> % + sbp->f_bfree = sfp->sf_fbytes / NFS_FABLKSIZE; > >> % + sbp->f_bavail = sfp->sf_abytes / NFS_FABLKSIZE; > >> > >> The conversion for f_bavail still has sign extension bugs. f_bavail > >> can be negative on the server. A non-broken (FreeBSD) server passes > >> us this negative value as a uint64_t value with the top bit set. > > > > Well, both RFC1813 (NFSv3) and RFC3530 (NFSv4) specify the value on > > the wire (sf_abytes) as uint64_t. Therefore a negative value can't > > be represented safely and non-FreeBSD clients/servers would be > > confused by cheating and putting the negative value on the wire. > > (I see you mention this further down.) > > But it can be represented. FreeBSD servers always put it on the wire > (if the server file system has a negative value) until the old nfs > server broke it. I can only find a few FreeBSD clients that aren't > confused by this: > - most or all clients work for the v2 case, because v2 doesn't need > to scale for f_bavail, and copying the 31st (unsigned) bit to > the 31st (signed) bit mostly works (except everthing breaks once > the absolute values exceed 2**31-1 or 2**32.1). > - most clients are broken for the v3 case. For negative f_bavail, > sign-extension/overflow bugs in the scaling give a value of about > 2**54. Assigning this to a 32-bit f_bavail gives unobvious garbage; > assigning this to a 64-bit f_bavail gives obvious garbage. > - my FreeBSD-~5.2 v3 client handles negative f_bavail correctly (by > scaling a signed value). It doesn't fix f_ffree. (I see negative > f_bavail quite often but never run into the reserve for f_ffree.) > Well my concern isn't w.r.t. FreeBSD clients, but other ones. I'll start a discussion on freebsd-fs@ about whether a FreeBSD server should "cheat" and put negative values (which other clients will think are large positive values) on the wire or try and conform strictly to the RFC. > BTW, how does scaling of block counts by NFS_FABLKSIZE in the v3 (and > v4?) cases work? I can only see it in clients. Servers seem to start > with block counts and never convert to byte counts. > It must be somewhere, since they are uint64_t byte counts on the wire, except for NFSv2, which used block counts of the block size provided in the same response. > > The new server is broken in that it does not > > check for a negative value. It seems that the best approach for the > > server would be to send a 0 when f_bavail < 0. What else can you do > > Hrmph. It is servers that check and send a 0 when f_bavail < 0 that > are broken. > > > without "cheating" and representing the value in a way that would be > > non-interoperable with non-BSD NFS clients? > > I don't know. See the NetBSD client for some ideas. Note that for > blocks > there are 2 "free" fields, f_bfree and f_bavail, while for files there > is > only 1 (f_ffree). You would think that the redundancy for blocks would > allow passing a negative value as the difference of 2 nonnegative > ones, > but I couldn't make this work. For FreeBSD clients that can handle > this, > is it possible to negotiate the handling with the server? Not that I know of. The spec writers got pretty irate when someone suggested that, for NFSv4, there should be a "vendorId", so clients could use that to handle things differently. Their outlook was that everyone should play by the same rules. I'll try and make my Solaris10 box get to -ve frees and then see what it puts on the wire. After that, I'll start a discussion on freebsd-fs@ about how they think a FreeBSD server should behave when f_bavail and/or f_ffree are negative. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?135141673.835577.1304282609097.JavaMail.root>