> Date: Fri, 21 Aug 2009 12:01:46 -0700 > From: Don Cragun <dcragun at sonic.net> > Subject: Re: PSARC/2009/453 - futimens, utimensat > To: "Garrett D'Amore" <gdamore at sun.com> > Cc: Roger.Faulkner at sun.com, lists at mcintyreweb.com, psarc-ext at > sun.com, Pavel.Filipensky at sun.com, Bart.Smaalders at sun.com > X-Brightmail-Tracker: AAAAAA== > X-Antispam: No, score=0.0/5.0, scanned in 2.180sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ > > Garrett D'Amore wrote: > > Don Cragun wrote: > >> On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > >> > ... ... ... > >> > >> I believe this project is incomplete without also adding support for > >> these to the fpathconf() and pathconf() functions and the getconf > >> utility. > >> > > > > Hm.... it seems that these should definitely be added. I'm happy for > > them to be added to this project, but I'm not sure it is *required*. > > > > Indeed, the pathconf/fpathconf changes should probably have been made at > > the time ZFS introduced nanosecond resolution. > > I don't remember exactly when ZFS introduced nanosecond resulution, but > I don't think the changes being presented here for [f]pathconf() were in > the standard at that time. Normally, this would be added when the SUSv4 > conformance project is added to the system, ... but I haven't heard of > any plans for that project since I left Sun. From the outside, it > appears that Sun is picking up some pieces of the standard without plans > to implement full conformance to the standard. ;-{ If that is the > case, I think it is important to be sure that these connected pieces of > the standard are all implemented as a single project. > > - Don
I'm in agreement with the sentiment expressed here, and in fact I made the changes to support the pathconf() name _PC_TIMESTAMP_RESOLUTION in all the local file systems. ufs returns 1000 and zfs returns 1. However, there is a problem with nfs. There is no over-the-wire protocol in nfs that can query the timestamp resolution of a remote file system. nfs's pathconf() issues one query to get a big block of attributes from the server and all of these attributes are fixed. There is no over-the-wire pathconf() call for new, individual _PC_* names. nfs V3 and V4 both pass nanosecond-resolution time values over the wire, and utimensat() and futimens() will set nanosecond resolution time stamps on remotely-mounted file systems if the remote filesystems are zfs on the server side But you can't (at least I can't) get the remote file system's time stamp resolution by any means other than actually attempting a utimensat() on it and examining the result with stat(). Can you live with pathconf(_PC_TIMESTAMP_RESOLUTION) returning -1 (with errno == EINVAL) for nfs-mounted files? Roger
