From owner-freebsd-fs@FreeBSD.ORG Sun May 1 21:25:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DACEC1065672 for ; Sun, 1 May 2011 21:25:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8438FC12 for ; Sun, 1 May 2011 21:25:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJvOvU2DaFvO/2dsb2JhbACEUaJDpFiNAo9IgSqDVYEBBI55hnyHQg X-IronPort-AV: E=Sophos;i="4.64,299,1301889600"; d="scan'208";a="119251971" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 01 May 2011 17:25:11 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CCD1CB3F2D for ; Sun, 1 May 2011 17:25:11 -0400 (EDT) Date: Sun, 1 May 2011 17:25:11 -0400 (EDT) From: Rick Macklem To: FreeBSD FS Message-ID: <1404795089.836227.1304285111779.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Subject: RFC: NFS server handling of negative f_bavail? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 21:25:12 -0000 Hi, I recently discovered that there seems to be an issue w.r.t. the f_bavail and f_ffree fields of "struct statfs" since they are signed values that can be negative. The RFCs for NFSv3 and NFSv3 define these fields as unsigned byte counts when they go on the wire. I read that as implying that negative values can't be represented for them? I tried a quick test on Solaris10, but I couldn't get the fields to go negative (they appear to be unsigned in their "struct statvfs"), so I couldn't find out what it would have done for negative values. I can think of 2 ways to go: 1 - Have the server reply 0 for these fields when VFS_STATFS() passes negative values up. This would seem to conform to the RFCs and seems least likely to confuse non-BSD clients. OR 2 - Put the signed value in the uint64_t on the wire. The risk here is that some clients will assume it's a large positive value. I admit I don't see the client knowing that the value is negative instead of 0 as being a big issue for an NFS client mount and am leaning towards #1, but I'm not familiar with what utilities might care about the value being negative? Anyhow, any comments? rick