[PATCH] Use vfs_timestamp() instead of getnanotime() in NFS
John Baldwin
jhb at freebsd.org
Fri Jan 18 17:13:18 UTC 2013
On Friday, January 18, 2013 1:19:29 am Bruce Evans wrote:
> On Thu, 17 Jan 2013, Rick Macklem wrote:
>
> > John Baldwin wrote:
> >> On Tuesday, January 15, 2013 2:58:42 pm John Baldwin wrote:
> >>> Fixing NFS to properly use vfs_timestamp() seems to be a larger
> >>> project.
> >>
> >> Actually, I have a patch that I think does this below. It builds, have
> >> not
> >> yet booted it (but will do so in a bit).
> >>
> >> Index: fs/nfsclient/nfs_clstate.c
> >> ===================================================================
> >> --- fs/nfsclient/nfs_clstate.c (revision 245225)
> >> +++ fs/nfsclient/nfs_clstate.c (working copy)
> >> @@ -4611,7 +4611,7 @@
> >> }
> >> dp = nfscl_finddeleg(clp, np->n_fhp->nfh_fh, np->n_fhp->nfh_len);
> >> if (dp != NULL && (dp->nfsdl_flags & NFSCLDL_WRITE)) {
> >> - NFSGETNANOTIME(&dp->nfsdl_modtime);
> >> + vfs_timestamp(&dp->nfsdl_modtime);
> >> dp->nfsdl_flags |= NFSCLDL_MODTIMESET;
> >> }
> >> NFSUNLOCKCLSTATE();
> > Not sure about this case. Although nfsdl_modtime is being set for local
> > use, it replaces the mtime returned by the NFS server while the delegation
> > is in use. Ideally it would be the same resolution as the NFS server, but
> > that resolution isn't known to the client. (It is often better than 1sec,
> > which is the default for vfs_timestamp().)
>
> The patch seems about right except for this.
>
> > I'd be tempted to leave it (although the function used by the macro might
> > need to be changed, since Bruce mentions getnanotime() isn't supposed to
> > be used?).
>
> For maximal precision and accuracy, it nanotime() should be used. I'm
> not sure if you need to be at least as precise and accurate as the server.
> Having them synced to nanoseconds accuracy is impossible, but
> getnanotime() gives <= 1/HZ of accuracy and it is easy for them to be
> synced with more accuracy than that. Then the extra accuracy can be
> seen in server timestamps if the server is FreeBSD and uses vfs_timestamp()
> with a either microtime() or nanotime().
I've certainly seen NFS servers use much more finely-grained VFS timestamps
(e.g. Isilon nodes run with vfs.timestamp_precision of 2 or 3 so they give
more precise timestamps than just getnanotime()). OTOH, clock drift between
the client and server could easily screw this up. I will leave this as-is
for now and just commit the vfs_timestamp() changes first.
> Further style fixes:
> - remove the NFSGETNANOTIME() macro. It is only used in the above, and
> in 3 other instances where its use is bogus because only the seconds
> part is used. The `time_second' global gives seconds part with the
> same (in)accuracy as getnanotime(). If you want maximal accuracy
> for just the seconds part, then bintime() should be used (this is
> slightly faster than microtime() and nanotime().
> (get*time()'s seconds part is the same as time_second. This
> inaccurate since it lags bintime()'s seconds part by up to 1/HZ
> seconds (so it differs by a full second for an everage of 1 one
> in every HZ readings). The difference is visible if one reader,
> say make(1) reads the time using bintime() while another reader,
> say vfs_timestamp() reads the time using getbintime().)
Yes, I wondered if I could replace those with time_second. The same
is true of the remaining uses of NFSGETTIME() as they also only use the
seconds portion.
--
John Baldwin
More information about the freebsd-fs
mailing list