Change default VFS timestamp precision?

Jilles Tjoelker jilles at stack.nl
Wed Dec 17 20:55:24 UTC 2014


On Wed, Dec 17, 2014 at 10:43:55AM +1100, Bruce Evans wrote:
> On Tue, 16 Dec 2014, John Baldwin wrote:
> > I'm less sure of what to do for other cases such as i386/amd64 when
> > not using TSC, or on other platforms.  OTOH, perhaps you aren't
> > doing lots of heavy I/O access on a system with a slow timecounter
> > (or if you are doing heavy I/O, slow timecounter access won't be
> > your bottleneck)?

> File times are rarely updated since the updates are normally delayed (except
> in devfs, where accurate times are least needed so caching would be most
> beneficial).  But the caching means that increasing the timestamp precision
> won't help much to fix the problem with make.  Consider build activity
> where there are a lot of writes which produce cached mtimes.  Some time
> later, make runs and causes these times to be updated by stat()ing the
> files.  It then sees times that are about the same, and likely to be out
> of order with respect to the actual writes.  Extra precision actually
> makes the problem worse: with seconds precision, make usually sees the
> same time for all files, but with nanoseconds precision it sees its own
> stat() order.  The extra precision is only helpful when there is a
> certain serialization of the stat()s relative to the build operations.

This would be strange and indeed it does not work that way. Per POSIX,
timestamps marked for update must also be updated when the file ceases
to be open by any process; FreeBSD updates them on any file close
(VOP_CLOSE). Therefore, the timestamps reflect at latest the time the
files were closed, when looked at after the writing program is done.

The problems you describe only occur when the affected files remain
open, which is not the case in usual build processes.

-- 
Jilles Tjoelker


More information about the freebsd-arch mailing list