On Fri, 21 Aug 2009 12:01:46 -0700, Roger A. Faulkner wrote:
>> 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?
Yes. It sounds to me like you have done the "right thing" here. One of
the meanings of EINVAL listed in the standard is "The implementation
does not support an association of the variable name with the specified
file." and you're saying that NFS doesn't support an association of
TIMESTAMP_RESOLUTION with NFS mounted files. However, please also file
a bug against NFS asking that the protocol be extended to provide this
information.
Thanks,
Don
>
> Roger
