[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making test(1)'s -nt/-ot ignore nanosecond fractions
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
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
/__ __ 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"