Date: Wed, 17 Dec 2014 00:38:44 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Change default VFS timestamp precision? Message-ID: <20141216233844.GA1490@stack.nl> In-Reply-To: <201412161348.41219.jhb@freebsd.org> References: <201412161348.41219.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 16, 2014 at 01:48:41PM -0500, John Baldwin wrote: > We still ship with vfs.timestamp_precision=0 by default meaning that > VFS timestamps have a granularity of one second. It is not unusual on > modern systems for multiple updates to a file or directory to occur > within a single second (and thus share the same effective timestamp). > This can break things that depend on timestamps to know when something > has changed or is stale (such as make(1) or NFS clients). On hardware > that has a cheap timecounter, I we should use the most-precise > timestamps (vfs.timestamp_precision=3). However, 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)? > I can think of a few options: > 1) Change vfs.timestamp_precision default to 3 for all systems. > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 using an > #ifdef. > 3) Something else? Although some breakage may be caused, increasing precision sounds fine to me, but only to the level of microseconds, since there is no way to set a timestamp to the nanosecond (this would be futimens/utimensat). It is easy to be surprised when cp -p creates an file that appears older than the original. To avoid cross-arch surprises with applications that use second-resolution APIs, either all or no architectures should generate timestamps more accurate than seconds. There is no benefit for the particular case of make(1), since it only uses timestamps in seconds. A quick grep also shows various calls to utime(3) with a non-NULL timep argument. The ones in contrib/bmake and usr.bin/make definitely look incorrect. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141216233844.GA1490>