Re: [RFC] nanoseconds vs. the epoch

J. Bruce Fields wrote:

>Peter Staubach wrote:
>  
>
>>Alexandre Ratchov wrote:
>>    
>>
>>>IMHO, having a global (per host) serial number that is incremented at
>>>each file system operation could solve most of these issues.
>>>      
>>>
>>This serial number, ala the generation count which was added for NFS,
>>would certainly have addressed the "has the file changed" issue, if it
>>had been added 20+ years ago.  Now, there is no support in the NFS
>>protocols for such.  Support could be added to a future revision of
>>the NFSv4 protocol, but that is quite some time away.
>>    
>>
>
>No, what Alexandre describes is exactly what NFSv4 already depends on
>for cache revalidation; see the description of the "change" attribute
>under section 5.5 of rfc3530:
>
>	"A value created by the server that the client can use to
>	determine if file data, directory contents or attributes of the
>	object have been modified.  The server may return the object's
>	time_metadata attribute for this attribute's value but only if
>	the filesystem object can not be updated more frequently than
>	the resolution of time_metadata."
>
>This is a 64-bit value, and is a mandatory, per-file attribute.
>
>So really what we want is something that's guaranteed to change with
>each filesystem operation.  Increasing timestamp resolution won't do
>that on its own.  For example, running the appended test program on my
>laptop, on an xfs filesystem, produces the following output:
>
>bfields@puzzle:xfs$ ~/projects/test/test_ctime
>success
>before mkdir: ctime:1144116895.55622681
>              mtime:1144116895.55622681
>after mkdir:  ctime:1147959633.236545203
>              mtime:1147959633.236545203
>after rmdir:  ctime:1147959633.236545203
>              mtime:1147959633.236545203
>
>So even though xfs has nanosecond-resolution times, the ctime and mtime don't
>change after the rmdir, I suppose because the actual timesource is something
>lower-resolution like jiffies.
>
>I can see the same problem on a loopback-mounted nfsv4 export of an xfs
>filesystem, though only intermittently.  I don't think I've reproduced it over
>a real network, but I also haven't tried very hard.
>
>Since the point of ctime, for many users (not just nfs), is to actually find
>out whether a file has changed, it would seem very useful to have a something
>that was actually *guaranteed* to act like a real change attribute.
>

The NFSv4 changeinfo attribute is the way that such a thing would be passed
over the wire.  You are right.

I was thinking along historical lines.  If such a notion had been thought
of early enough, it would have been implemented and then spread throughout
other systems as NFSv2 and then NFSv3 implementations proliferated.  The
generation count is an example of something that the early NFS developers
found the need for and included and now, it exists in many systems.

   Thanx...

      ps