From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 22:08:15 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 C281A6BE for ; Tue, 16 Dec 2014 22:08:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CC28A2D for ; Tue, 16 Dec 2014 22:08:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 366F5B945; Tue, 16 Dec 2014 17:08:14 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: Change default VFS timestamp precision? Date: Tue, 16 Dec 2014 14:37:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201412161348.41219.jhb@freebsd.org> <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> In-Reply-To: <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201412161437.16767.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Dec 2014 17:08:14 -0500 (EST) 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 22:08:15 -0000 On Tuesday, December 16, 2014 1:51:09 pm Warner Losh wrote: >=20 > > On Dec 16, 2014, at 11:48 AM, John Baldwin wrote: > >=20 > > We still ship with vfs.timestamp_precision=3D0 by default meaning that = VFS > > timestamps have a granularity of one second. It is not unusual on mode= rn > > systems for multiple updates to a file or directory to occur within a s= ingle > > second (and thus share the same effective timestamp). This can break t= hings > > that depend on timestamps to know when something has changed or is stal= e (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=3D3). = 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 hea= vy 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)? > >=20 > > I can think of a few options: > >=20 > > 1) Change vfs.timestamp_precision default to 3 for all systems. > >=20 > > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 usin= g an > > #ifdef. > >=20 > > 3) Something else? > >=20 > > What do other folks think? >=20 > (1). If there=E2=80=99s a specific kernel / platform that=E2=80=99s slow,= we can make it an option > for those kernels. Mm, so something like: Index: vfs_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- vfs_subr.c (revision 275828) +++ vfs_subr.c (working copy) @@ -632,7 +632,11 @@ vfs_getnewfsid(struct mount *mp) */ enum { TSP_SEC, TSP_HZ, TSP_USEC, TSP_NSEC }; =20 +#ifdef VFS_CHEAP_TIMESTAMPS static int timestamp_precision =3D TSP_SEC; +#else +static int timestamp_precision =3D TSP_NSEC; +#endif SYSCTL_INT(_vfs, OID_AUTO, timestamp_precision, CTLFLAG_RW, ×tamp_precision, 0, "File timestamp precision (0: seconds, " "1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, " where VFS_CHEAP_TIMESTAMPS becomes a new kernel config option? (We should also probably make this a loader tunable) =2D-=20 John Baldwin