From owner-freebsd-fs@FreeBSD.ORG Sat Feb 11 07:20:30 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22EEA1065670 for ; Sat, 11 Feb 2012 07:20:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2788FC18 for ; Sat, 11 Feb 2012 07:20:29 +0000 (UTC) Received: by lagz14 with SMTP id z14so4374177lag.13 for ; Fri, 10 Feb 2012 23:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uv0EutbvBHWoXJevs2st0BRq6RP2IHdo/W00IVEhagE=; b=eVlXxDIjNWaulqRNgQzQ2yOrGw+6Fcn+MBxJUSJghERgfB3PTnef91e2tO3giVqTJL lv1OMTkQCIF7tL2sIHNxrEKxBNprGaQFUYWUyB2ucvXwmCzyO3Nuswq7GlfJAJzbQV/n y3A8XglMzIzvamS9NZSswBFw0zOUQmxsMlKOQ= MIME-Version: 1.0 Received: by 10.152.122.74 with SMTP id lq10mr6830632lab.7.1328944828191; Fri, 10 Feb 2012 23:20:28 -0800 (PST) Received: by 10.152.18.4 with HTTP; Fri, 10 Feb 2012 23:20:28 -0800 (PST) In-Reply-To: <20120211121947.M903@besplex.bde.org> References: <20120210135527.GR1860@hoeg.nl> <20120211042121.B3653@besplex.bde.org> <20120211121947.M903@besplex.bde.org> Date: Sat, 11 Feb 2012 10:20:28 +0300 Message-ID: From: Sergey Kandaurov To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , fs@freebsd.org Subject: Re: Increase timestamp precision? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 07:20:30 -0000 On 11 February 2012 06:10, Bruce Evans wrote: > PS: > > > On Sat, 11 Feb 2012, Bruce Evans wrote: > >> On Fri, 10 Feb 2012, Sergey Kandaurov wrote: >> >>> On 10 February 2012 17:55, Ed Schouten wrote: >>>> >>>> Hi all, >>>> >>>> It seems the default timestamp precision sysctl >>>> (vfs.timestamp_precision) is currently set to 0 by default, meaning we >>>> don't do any sub-second timestamps on files. Looking at the code, it >>>> seems that vfs.timestamp_precision=3D1 will let it use a cached value = with >>>> 1 / HZ precision and it looks like it should have little overhead. >>>> >>>> Would anyone object if I were to change the default from 0 to 1? >> >> >> Sure. =A0The setting of 1 is too buggy to use in its current implementat= ion. >> I don't know of any fixed version, so there is little experience with >> a usable version. =A0I also wouldn't use getnanotime() for anything. >> But I like nanotime(). > > > [ ... the bugs are that it gives nanoseconds precision with garbage in th= e > low bits, and shares an old bug with a setting of 0 (TSP_SEC) ] > > Other bugs near here: > - vfs.timestamp_precision is still global, so you can't change the defaul= t > =A0for individual mount points or even for individual vfs's. =A0The globa= l > =A0is only good enough for a quick hack. Agreed. :-/ That is the main obstacle in my pov why it was not changed yet. > - touch(1) normally uses gettimeofday() and utimes(). =A0Thus it normally > =A0gives microseconds precision and hopefully close to microseconds > =A0accuracy (if you are using ntpd). =A0But when utimes() fails due to > =A0insufficient security and the user didn't specify a time, touch(1) > =A0falls back to using utimes() with a null timeptr, to ask the kernel > =A0to use the current time. =A0The kernel uses vfs_timestamp() for this, > =A0so it sets times incompatibitly with touch(1) unless > =A0vfs.timestamp_precision=3D2 (TSP_USEC). =A0The kernel used to use > =A0microtime() for this, but it was changed in 2009 to use > =A0vfs_timestamp(), with no reason given in its log message except a > =A0cryptic pointer to a Debian PR. =A0The bug is mostly in touch(1). > - the recently-removed fallback to setting times by writing in touch(1) > =A0gave another incompatible way of setting times. In POSIX-2008 touch description mentions now that touch shall perform actions equivalent to futimens() or utimensat() (see below) depending on whether the specified file exists. It also introduces the concept of finegrained timestamps - a fractional part of second like: touch -d "2007-11-12 10:15:30.002Z" -d is a new way to specify your own time but in ISO 8601:2000 format > Timstamping bugs not so near here: > - POSIX.1-1988 avoided the design error and unportability of timevals > =A0by inventing timespecs. =A0It failed to invent an interfaces to set > =A0these. =A0It only has utime(), which only sets times in seconds. > - POSIX.1-2001 restored the design error of timevals, and utimes() > =A0to set them (but utimes() was marked as legacy). =A0It still failed to > =A0invent an interface to set its own timespecs. > - POSIX is apparently inventing futimesat(). =A0This only sets timevals. > =A0POSIX is apparently still failing to invent an interface to set its > =A0own timespecs. =A0Any utime()-like interface invented after timespecs > =A0should support timespecs, with setting timevals only supported by > =A0compatibility cruft in this interface.[...] =A0futimesat() is unfortun= ately being > =A0standardized[..] POSIX.1-2008 invented two *utimes() syscalls since then which both operate on timespecs. I implemented them a year ago, but failed to commit yet for some reason, particularity because of overcomplicated utimes(2) man page. - futimens() is like our futimes() but works with timespec(); - utimensat() is like our futimesat(). It is "ours" because it was never standardized. Our manpage for futimesat() only mentions that it "follows The Open Group Extended API Set 2 specification." Linux manpage provides somewhat better history: This system call is nonstandard. It was implemented from a specification = that was proposed for POSIX.1, but that specification was replaced by the one f= or utimensat(2). utimensat() diverges from futimesat() by enabling usage of timespec and addition of the optional flag with only one existing bit that follows other *at() family convention: AT_SYMLINK_NOFOLLOW If path names a symbolic link, the symbolic link's dates are changed. --=20 wbr, pluknet