From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 14:42:04 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A2416A4CE for ; Sat, 15 Nov 2003 14:42:04 -0800 (PST) Received: from sweeper.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id E444A43FB1 for ; Sat, 15 Nov 2003 14:42:02 -0800 (PST) (envelope-from peter.edwards@openet-telecom.com) Received: from mail.openet-telecom.com (unverified) by sweeper.openet-telecom.com ; Sat, 15 Nov 2003 22:42:56 +0000 Received: from [194.125.181.49] by mail.openet-telecom.com with HTTP; Sat, 15 Nov 2003 22:37:09 +0000 Date: Sat, 15 Nov 2003 22:37:09 +0000 Message-ID: <3FB4BA030000006E@mail.openet-telecom.com> In-Reply-To: <3FB6A47D.76F3DAE9@mindspring.com> From: peter.edwards@openet-telecom.com To: "Terry Lambert" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: Who needs these silly statfs changes... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 22:42:04 -0000 (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 exabyte= s >of >> >>>>free space! > >[ ... ] > >> The NFS protocols have unsigned fields where statfs has signed >> equivalents: NFS can't represent negative available disk space ( Witho= ut >> the knowledge of the underlying filesystem on the server, negative fre= e >> 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 :-)