From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 14:58:54 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BC6778C for ; Wed, 17 Dec 2014 14:58:54 +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 0532E97C for ; Wed, 17 Dec 2014 14:58:54 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D3893B982; Wed, 17 Dec 2014 09:58:52 -0500 (EST) From: John Baldwin To: Erik Cederstrand Subject: Re: Change default VFS timestamp precision? Date: Wed, 17 Dec 2014 09:34:38 -0500 Message-ID: <1524396.mnvXrYilFC@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> References: <201412161348.41219.jhb@freebsd.org> <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 17 Dec 2014 09:58:52 -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: Wed, 17 Dec 2014 14:58:54 -0000 On Wednesday, December 17, 2014 10:04:08 AM Erik Cederstrand wrote: > > Den 16/12/2014 kl. 19.48 skrev John Baldwin : > > > > 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