From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 15:58:57 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 279D016A4CE for ; Fri, 14 Nov 2003 15:58:57 -0800 (PST) Received: from sweeper.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5313D43F93 for ; Fri, 14 Nov 2003 15:58:53 -0800 (PST) (envelope-from peter.edwards@openet-telecom.com) Received: from mail.openet-telecom.com (unverified) by sweeper.openet-telecom.com ; Fri, 14 Nov 2003 23:59:44 +0000 Received: from [194.125.183.33] by mail.openet-telecom.com with HTTP; Fri, 14 Nov 2003 23:54:03 +0000 Date: Fri, 14 Nov 2003 23:54:03 +0000 Message-ID: <3FB4BA0300000058@mail.openet-telecom.com> In-Reply-To: <20031115090010.E10413@gamplex.bde.org> From: peter.edwards@openet-telecom.com To: "Bruce Evans" 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: Fri, 14 Nov 2003 23:58:57 -0000 >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 ( Wi= thout >> >> 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 fiel= ds >> > 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 lyi= ng >> 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 negati= ve. >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 stru= ct >statfs in FreeBSD. The casts to long are now just wrong since the block= >count fields don't have type long. Sure.