Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Dec 2014 15:41:32 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        arch@freebsd.org
Subject:   Re: Change default VFS timestamp precision?
Message-ID:  <12A1D992-44B8-4FB6-A069-EB7635D54914@bsdimp.com>
In-Reply-To: <201412161437.16767.jhb@freebsd.org>
References:  <201412161348.41219.jhb@freebsd.org> <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> <201412161437.16767.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Dec 16, 2014, at 12:37 PM, John Baldwin <jhb@FreeBSD.org> wrote:
>=20
> On Tuesday, December 16, 2014 1:51:09 pm Warner Losh wrote:
>>=20
>>> On Dec 16, 2014, at 11:48 AM, John Baldwin <jhb@freebsd.org> 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 =
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=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 =
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)?
>>>=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 =
using 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.
>=20
> Mm, so something like:
>=20
> 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
> --- 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,
>     &timestamp_precision, 0, "File timestamp precision (0: seconds, "
>     "1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, "
>=20
> where VFS_CHEAP_TIMESTAMPS becomes a new kernel config option?
>=20
> (We should also probably make this a loader tunable)

Yea, the DEFAULT behavior should be set at compile time, the run-time =
behavior should be set by this variable=E2=80=A6. Tunable is good too, =
but the sysctl likely will suffice for that given how early the =
sysctl.conf file is snarfed.

Warner

--Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUkLUcAAoJEGwc0Sh9sBEA2KwP/3GIsl+aQjVntSbVtcajeoa+
v/bnG27WqpoUNOu0S6IQYJ0DlKmCPDD4Z19Jq7OpOAEa+53779NOWd3AQYeYp9s1
AlZygZQJ1p7jisQtrCYUOqbvCjZFw7AtQ6n/DqrnsmKr5fOtno0XUEQyN+z/ps/7
TgDoGREgMcjMOWvn1F25rfkTH7eWgD+N+Dzusj7TgLV3cchz5XPEQRHLi+YOK8ab
l7umz5AiEFd7CrCOGrA/2BqoXUxlPvbtfL14t2DHmOoy3XDX864r6jKNAy/tGugi
08wJTt9FmibhBZh6FSpYt1IM3d3AHTLO9Dt63EWENsM1xrEZaNEL2EKS91Hs8+3Y
UEsVYKF0hltJm17QX2InLa6K4eqFyIi+SzTB66ucI89I+yz3ZzSWZmGoSRsOwniz
tXnS8GdPTuejU+5yA6qILmNbD6qxHrblspcwsrFeaT3gK3gaGL/oaPXjh6Sllqmx
+DyhpPtQ3T0MiYQb0GDdxi1wARuFGaA1jC3ufSrCHmXglufQIyvHvnXc1w35AAQx
393JnS1TsZ8HphASPCiBzy91ttWcGkdLPAlX8ZJR4wBpP5FMqcJJQvRGo82NL9Hx
48Jz3lHpFMGRG8RlQRe33x1GiNR6fsLqBY8m1zgpFeQHbHIxGxYgWIF3nriDw51H
/yPl6Qhjw/31tc4kJ8mq
=m60X
-----END PGP SIGNATURE-----

--Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12A1D992-44B8-4FB6-A069-EB7635D54914>