> Date: Thu, 27 Aug 2009 16:35:25 -0500 > From: Nicolas Williams <Nicolas.Williams at sun.com> > Subject: Re: PSARC/2009/453 - futimens, utimensat > To: "Garrett D'Amore" <gdamore at sun.com> > Cc: "Roger A. Faulkner" <Roger.Faulkner at sun.com>, psarc-ext at sun.com, Pavel.Filipensky at sun.com, Bart.Smaalders at sun.com, Krister.Johansen at sun.com, Darrin.Johnson at sun.com, Joerg.Schilling at fokus.fraunhofer.de, lists at mcintyreweb.com, dcragun at sonic.net, roland.mainz at nrubsig.org > > On Thu, Aug 27, 2009 at 03:27:38PM -0500, Nicolas Williams wrote: > > On Thu, Aug 27, 2009 at 01:02:52PM -0700, Garrett D'Amore wrote: > > > +1 on the revised spec. > > > > > > It seems like (not this project) someone ought to pursue getting support > > > for high resolution timestamps into the next NFS specification. > > > > Conveniently, the IETF NFSv4 WG is looking for work items for NFSv4.2. > > I've just sent a short note to the WG mailing list about this issue. > > Actually, NFSv3 and NFSv4 already have this. I think our server just > sets this to a constant, and our client doesn't use it. > > So just file a CR against solaris/kernel/nfs? > > Nico
I know that NFSv3 and NFSv4 send nanosecond-resolution timestamps over the wire. That's not the problemm. The problem is that the remotely-mounted file system may or may not honor such timestamps. For example, a remotely-mounted UFS file system will only honor microsecond-resolution timestamps. But the client side doesn't know that. It's just an NFS-mounted file system as far as the client knows. What is needed is a VOP_PATHCONF(_PC_TIMESTAMP_RESOLUTION) operation for NFS that returns the actual timestamp resolution for the underlying file system. Roger
