From owner-freebsd-fs@FreeBSD.ORG Sun May 1 20:27:25 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E1DC106566B; Sun, 1 May 2011 20:27:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A28378FC0A; Sun, 1 May 2011 20:27:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEALjBvU2DaFvO/2dsb2JhbACEUaJCiHGpBI9JhH+BAQSOeY4+ X-IronPort-AV: E=Sophos;i="4.64,299,1301889600"; d="scan'208";a="120083406" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 May 2011 16:27:23 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 953DCB3FB5; Sun, 1 May 2011 16:27:23 -0400 (EDT) Date: Sun, 1 May 2011 16:27:23 -0400 (EDT) From: Rick Macklem To: Bruce Evans Message-ID: <733531363.835298.1304281643548.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110502035720.F2645@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_835297_766810430.1304281643545" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: rmacklem@freebsd.org, kib@freebsd.org, fs@freebsd.org Subject: Re: newnfs client and statfs 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 20:27:25 -0000 ------=_Part_835297_766810430.1304281643545 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > On Sun, 1 May 2011, Rick Macklem wrote: > > >> UINT64_MAX, etc., are defined in , which doesn't even > >> need > >> to be included explicitly, since it is (bogusly) standard namespace > >> pollution in . This namespace pollution gives the > >> bizarre > >> ... > > > Ok, now I see them (in machine/include/_stdint.h). Appologies for > > the > > noise. I grep'd sys/sys and couldn't find anything called > > (U)INT64_MAX. > > > > Now, remembering that sf_abytes is uint64_t per the RFCs, what do > > people > > think of either of these? > > > > if (sfp->sf_abytes > INT64_MAX) > > sbp->f_bavail = INT64_MAX; > > else > > sbp->f_bavail = sfp->sf_abytes / NFS_FABLKSIZE; > > You don't need to do anything at runtime, since everything is 64 bits > and f_bavail is a block count while sf_abytes is a byte count. 1 bit > is lost to the sign bit in f_bavail, but 9 bits are gained by scaling > by NFS_FABLKSIZE, leaving 8 bits to spare. > > Calculating the limit at runtime would give INT64_MAX / > NFS_FABSBLKSIZE, > or perhaps 1 more than that (to round up instead of down). You might > still want to use an out-of-band limit like INT64_MAX for technical > reasons, but that risks more bugs (for example, anything converting > INT64_MAX / NFS_FABSBLKSIZE + 1 "back" to a byte count would overflow > and anything converting INT64_MAX "back" to a byte count would > overflow > even uint64_t. > > > Or should I try and do the division to see if the large > > value in sf_abytes will fit in INT64_MAX after the division? > > Something > > like: > > Runtime tests have the advantage of continuing to work if someone > changes > the types, provided they are robust, but making them robust is too > hard > here. Robust test's can't simply use INT64_MAX, since INT64_MAX is > only > the max if the type is int64_t... > Ok, I realized the code in the last post was pretty bogus:-) My only excuse was that I typed it as I was running out the door... So, I played with it a bit and the attached patch seems to work for i386. For the fields that are uint64_t in struct statfs, it just divides/assigns. For the int64_t field that takes the divided value (f_bavail) I did the division/assignment to a uint64_t tmp and then assigned that to f_bavail. (Since any value that fits in uint64_t is a positive value for int64_t after being divided by 2 or more, it will always be positive.) For the other int64_t one, I just check for "> INT64_MAX" and set it to INT64_MAX for that case, so it doesn't go negative. Anyhow, the updated patch is attached and maybe kib@ can test it? Thanks for the help with this. I realize I got rather confused during the discussion, rick ------=_Part_835297_766810430.1304281643545 Content-Type: text/x-patch; name=statfs.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=statfs.patch LS0tIGZzL25mc2NsaWVudC9uZnNfY2xwb3J0LmMuc2F2CTIwMTEtMDQtMzAgMjA6MTY6MzkuMDAw MDAwMDAwIC0wNDAwCisrKyBmcy9uZnNjbGllbnQvbmZzX2NscG9ydC5jCTIwMTEtMDUtMDEgMTY6 MTE6MTguMDAwMDAwMDAwIC0wNDAwCkBAIC04MzgsMjAgKzgzOCwxOSBAQCB2b2lkCiBuZnNjbF9s b2Fkc2JpbmZvKHN0cnVjdCBuZnNtb3VudCAqbm1wLCBzdHJ1Y3QgbmZzc3RhdGZzICpzZnAsIHZv aWQgKnN0YXRmcykKIHsKIAlzdHJ1Y3Qgc3RhdGZzICpzYnAgPSAoc3RydWN0IHN0YXRmcyAqKXN0 YXRmczsKLQluZnNxdWFkX3QgdHF1YWQ7CisJdWludDY0X3QgdG1wOwogCiAJaWYgKG5tcC0+bm1f ZmxhZyAmIChORlNNTlRfTkZTVjMgfCBORlNNTlRfTkZTVjQpKSB7CiAJCXNicC0+Zl9ic2l6ZSA9 IE5GU19GQUJMS1NJWkU7Ci0JCXRxdWFkLnF2YWwgPSBzZnAtPnNmX3RieXRlczsKLQkJc2JwLT5m X2Jsb2NrcyA9IChsb25nKSh0cXVhZC5xdmFsIC8gKCh1X3F1YWRfdClORlNfRkFCTEtTSVpFKSk7 Ci0JCXRxdWFkLnF2YWwgPSBzZnAtPnNmX2ZieXRlczsKLQkJc2JwLT5mX2JmcmVlID0gKGxvbmcp KHRxdWFkLnF2YWwgLyAoKHVfcXVhZF90KU5GU19GQUJMS1NJWkUpKTsKLQkJdHF1YWQucXZhbCA9 IHNmcC0+c2ZfYWJ5dGVzOwotCQlzYnAtPmZfYmF2YWlsID0gKGxvbmcpKHRxdWFkLnF2YWwgLyAo KHVfcXVhZF90KU5GU19GQUJMS1NJWkUpKTsKLQkJdHF1YWQucXZhbCA9IHNmcC0+c2ZfdGZpbGVz OwotCQlzYnAtPmZfZmlsZXMgPSAodHF1YWQubHZhbFswXSAmIDB4N2ZmZmZmZmYpOwotCQl0cXVh ZC5xdmFsID0gc2ZwLT5zZl9mZmlsZXM7Ci0JCXNicC0+Zl9mZnJlZSA9ICh0cXVhZC5sdmFsWzBd ICYgMHg3ZmZmZmZmZik7CisJCXNicC0+Zl9ibG9ja3MgPSBzZnAtPnNmX3RieXRlcyAvIE5GU19G QUJMS1NJWkU7CisJCXNicC0+Zl9iZnJlZSA9IHNmcC0+c2ZfZmJ5dGVzIC8gTkZTX0ZBQkxLU0la RTsKKwkJdG1wID0gc2ZwLT5zZl9hYnl0ZXMgLyBORlNfRkFCTEtTSVpFOworCQlzYnAtPmZfYmF2 YWlsID0gdG1wOworCQlzYnAtPmZfZmlsZXMgPSBzZnAtPnNmX3RmaWxlczsKKwkJaWYgKHNmcC0+ c2ZfZmZpbGVzID4gSU5UNjRfTUFYKQorCQkJc2JwLT5mX2ZmcmVlID0gSU5UNjRfTUFYOworCQll bHNlCisJCQlzYnAtPmZfZmZyZWUgPSBzZnAtPnNmX2ZmaWxlczsKIAl9IGVsc2UgaWYgKChubXAt Pm5tX2ZsYWcgJiBORlNNTlRfTkZTVjQpID09IDApIHsKIAkJc2JwLT5mX2JzaXplID0gKGludDMy X3Qpc2ZwLT5zZl9ic2l6ZTsKIAkJc2JwLT5mX2Jsb2NrcyA9IChpbnQzMl90KXNmcC0+c2ZfYmxv Y2tzOwo= ------=_Part_835297_766810430.1304281643545--