Re: [RFC] nanoseconds vs. the epoch

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?

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.

Have i missed something?

cheers,

-- 
Alexandre