Re: [RFC] nanoseconds vs. the epoch

Alexandre Ratchov wrote:

>On Wed, May 31, 2006 at 02:49:58PM -0600, Andreas Dilger wrote:
>  
>
>>A preliminary patch for nanosecond timestamps is underway.  I consider it
>>useful to take (at least) the top two bits of the ns timestamp as an extension
>>to the seconds field, extending the unix epoch on 64-bit systems by (at least)
>>272 years without needing more than a 64-bit timestamp.
>>
>>    
>>
>
>There is still a point that i don't understand:
>
>It seems that NFS implementations need to know whether or not a file has
>been changed since the last time it was accessed. IMHO, timestamps aren't
>meant to address this issue; for instance, there is no way to know if a file
>has been modified within a time slice. However, i agree that finer the
>resolution is smaller the probability to get it wrong is.
>
>But, in a NFS environment, timestamps aren't accurate; they are meaningful
>only if the clock difference between the client and the server is smaller
>than the time-stamp resolution. In a local area network, NTP could achieve
>1ms accuracy (is this true?).
>
>Could someone with a better NFS understanding correct me?
>
>  
>

Yes, I can.  :-)

NFS client side implementations do not need to be able to compare clock
times on the client against clock times on the server.  In fact, as you
indirectly pointed out, this is very problematic.

A good NFSv[23] client implementation keeps local times when appropriate
and compares server clock times against server clock times.  There is no
need to compare client times versus server times.

>IMHO, having a global (per host) serial number that is incremented at each
>file system operation could solve most of these issues. Indeed, most of the
>time, we want to know if a file is newer than another one or if it have
>changed since the last time it was accessed. If such an unique serial number
>is stored into the inode then we'll always be able to get the order of two
>operations. I think that we need strong ordering and not necessarily good
>time accuracy; Currently we are largely using timestamps because events are
>ordered in time, but IMHO this isn't the easier and/or the most reliable
>approach.
>
>  
>

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.

    Thanx...

       ps

>Have i missed something?
>
>cheers,
>
>  
>