Date: Mon, 2 May 2011 19:57:16 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Kostik Belousov <kostikbel@gmail.com> Cc: fs@FreeBSD.org Subject: Re: newnfs client and statfs Message-ID: <2119325179.903923.1304380636687.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110503020940.N2001@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Hi,
I have attached a version of the patch that I intend to commit
unless it doesn't work for Kostik's test case. Kostik, could
you please test this one.
Yes, Bruce, I realize you won't like it, but I
have put some comments in it
to try and clarify why it is coded the way it is.
(The arithmetic seems to work the way I would expect it to for
i386, which is the only arch I have for testing.)
If the "collective concensus" is to "cheat" and put the negative
values in the uint64_t on the wire, then I can commit a change
to handle that later. If anyone has input w.r.t. this, please post
it under the Subject heading "NFS server handling of negative f_bavail?"
on freebsd-fs@freebsd.org.
I basically need to move onto other issues, rick
[-- Attachment #2 --]
--- fs/nfsclient/nfs_clport.c.sav 2011-04-30 20:16:39.000000000 -0400
+++ fs/nfsclient/nfs_clport.c 2011-05-02 19:32:31.000000000 -0400
@@ -838,21 +838,33 @@ void
nfscl_loadsbinfo(struct nfsmount *nmp, struct nfsstatfs *sfp, void *statfs)
{
struct statfs *sbp = (struct statfs *)statfs;
- nfsquad_t tquad;
if (nmp->nm_flag & (NFSMNT_NFSV3 | NFSMNT_NFSV4)) {
sbp->f_bsize = NFS_FABLKSIZE;
- tquad.qval = sfp->sf_tbytes;
- sbp->f_blocks = (long)(tquad.qval / ((u_quad_t)NFS_FABLKSIZE));
- tquad.qval = sfp->sf_fbytes;
- sbp->f_bfree = (long)(tquad.qval / ((u_quad_t)NFS_FABLKSIZE));
- tquad.qval = sfp->sf_abytes;
- sbp->f_bavail = (long)(tquad.qval / ((u_quad_t)NFS_FABLKSIZE));
- tquad.qval = sfp->sf_tfiles;
- sbp->f_files = (tquad.lval[0] & 0x7fffffff);
- tquad.qval = sfp->sf_ffiles;
- sbp->f_ffree = (tquad.lval[0] & 0x7fffffff);
+ sbp->f_blocks = sfp->sf_tbytes / NFS_FABLKSIZE;
+ sbp->f_bfree = sfp->sf_fbytes / NFS_FABLKSIZE;
+ /*
+ * Although sf_abytes is uint64_t and f_bavail is int64_t,
+ * the value after dividing by NFS_FABLKSIZE is small
+ * enough that it will fit in 63bits, so it is ok to
+ * assign it to f_bavail without fear that it will become
+ * negative.
+ */
+ sbp->f_bavail = sfp->sf_abytes / NFS_FABLKSIZE;
+ sbp->f_files = sfp->sf_tfiles;
+ /* Since f_ffree is int64_t, clip it to 63bits. */
+ if (sfp->sf_ffiles > (uint64_t)INT64_MAX)
+ sbp->f_ffree = INT64_MAX;
+ else
+ sbp->f_ffree = sfp->sf_ffiles;
} else if ((nmp->nm_flag & NFSMNT_NFSV4) == 0) {
+ /*
+ * The type casts to (int32_t) ensure that this code is
+ * compatible with the old NFS client, in that it will
+ * sign extend a value with bit31 set. This may or may
+ * not be correct for NFSv2, but since it is a legacy
+ * environment, I'd rather retain backwards compatibility.
+ */
sbp->f_bsize = (int32_t)sfp->sf_bsize;
sbp->f_blocks = (int32_t)sfp->sf_blocks;
sbp->f_bfree = (int32_t)sfp->sf_bfree;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2119325179.903923.1304380636687.JavaMail.root>