making test(1)'s -nt/-ot ignore nanosecond fractions

[Akinori MUSHA]

Hello,

At Sun, 9 May 2004 00:48:27 +1000 (EST),
Bruce Evans wrote:
> >     - File timestamps are recorded in nanoseconds on a UFS, and
> >       sometimes a file's timestamp actually has >1000 nanosecond
                                                    <
> >       (= >1 microsecond) value.
             <
> 
> ffs uses vfs_timestamp() which gives a timestamp with the precision
> specified by vfs.timestamp_precision.  The default is 0 (TSP_SEC),
> which means that timestamps on files are normally in seconds with
> nanoseconds part 0.  This can be changed easily using sysctl, but
> changing the precision to the highest (nanoseconds) gives the bugs
> being discussed.  Changing it to microseconds precision is safer,
> since utimes(2) (but not utime(2) supports this precision.
> 
> The only other way to get ffs timestamps with a nonzero nanseconds
> part is to use utimes(), but this gives microseconds precision which
> utimes() can copy later.

Hm, I never changed vfs.timestamp_precision to anything other than the
default (nor even knew of it), but I acutually observed some files
having ...032 and ...256 nanoseconds on an NFS exported FFS on
4-STABLE.  I'm not sure if the files were created directly on FFS or
via NFS.

Does that mean there could be a bug somewhere around nanotime() calls?

-- 

> > [... details deleted]
> >     - Which means touch(1) or any other userland tool can only set a
> >       file's mtime in microseconds at most.
> > ...
> > In order to fix this, we could consider adding a syscall or extend
> > utimes(2) to take nanoseconds, but I'm afraid it would take a long
> > time before it becomes available on -STABLE and the API spread over
> > third-party applications.  So, I'd suggest the following simple fix to
> > make test(1) ignore such nanosecond fractions as a temporary measure:
> 
> It's already taken more than 10 years for for the API to make null
> progress matching the nanoseconds filesystem timestamps :(.
> 
> I think timestamps with a precision smaller than 1 microsecond should
> just not be made (don't support it in vfs_timestamp(), and fix all the
> file systems that use nanotime() directly).
> 
> Another problem with file times is that they can be older than the
> time at which they are made, due to shortcuts in time_second and
> getnanotime().  E.g., if the current time is N.009999 seconds so that
> time(3) returns N, then time_second may be (N-1) seconds, so file times
> may be 1 second older than the time at which they were made if
> vfs.timestamp_precision is the default.  Similarly, if
> vfs.timestamp_precision is 1 (TSP_HZ), then file times may be 1/HZ
> seconds older than the time at which they were made.  These bugs are
> missing if vfs.timestamp_precision is 2 (TSP_USEC) or 3 (TSP_NSEC).
> I've never needed more that seconds resolution AFAIK, but I sometimes
> use vfs.timestamp_precision=3 to avoid the bugs.
> 
> A vfs.timestamp_precision of 1 (TSP_HZ) is more broken than I remembered.
> It doesn't round the nanoseconds part to a multiple of 1/HZ or a multiple
> of 1000, so it gives timestamps that utimes() can't preserve for no
> benefit.

-- 
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"It seems to me as we make our own few circles 'round the sun
          We get it backwards and our seven years go by like one"