From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 23:38:48 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DD3C8AA; Tue, 16 Dec 2014 23:38:48 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E703B356; Tue, 16 Dec 2014 23:38:47 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5D7703592FF; Wed, 17 Dec 2014 00:38:44 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id B89D628494; Wed, 17 Dec 2014 00:38:44 +0100 (CET) Date: Wed, 17 Dec 2014 00:38:44 +0100 From: Jilles Tjoelker To: John Baldwin Subject: Re: Change default VFS timestamp precision? Message-ID: <20141216233844.GA1490@stack.nl> References: <201412161348.41219.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201412161348.41219.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 23:38:48 -0000 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