Date: Wed, 17 Dec 2014 09:34:38 -0500 From: John Baldwin <jhb@freebsd.org> To: Erik Cederstrand <erik@cederstrand.dk> Cc: arch@freebsd.org Subject: Re: Change default VFS timestamp precision? Message-ID: <1524396.mnvXrYilFC@ralph.baldwin.cx> In-Reply-To: <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> References: <201412161348.41219.jhb@freebsd.org> <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, December 17, 2014 10:04:08 AM Erik Cederstrand wrote: > > Den 16/12/2014 kl. 19.48 skrev John Baldwin <jhb@freebsd.org>: > > > > 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). > > Mistaking timestamps for uniqueness is really a design error of the > consumer. Changing granularity to milliseconds will diminish the problem, > but also create harder-to-debug problems when multiple updates do happen in > the same millisecond. Is there no other way than timestamps to find out if > a file has changed (apart from md5 which is too expensive)? For NFS v3 clients, no. And the bigger case is directories and knowing when to purge the results of cached lookups. Right now our NFS client defaults to a hard timeout of 60 seconds for any lookups it caches to limit the damage from losing races when a directory has multiple states that are associated with the same 'mtime'. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1524396.mnvXrYilFC>