Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Feb 2012 10:20:28 +0300
From:      Sergey Kandaurov <pluknet@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Ed Schouten <ed@80386.nl>, fs@freebsd.org
Subject:   Re: Increase timestamp precision?
Message-ID:  <CAE-mSOKpYH1U4_h1W8d5acb6JnwRGbVmz9zYo6S5JcCmVoDf7g@mail.gmail.com>
In-Reply-To: <20120211121947.M903@besplex.bde.org>
References:  <20120210135527.GR1860@hoeg.nl> <CAE-mSOK2fo=PsvyQWW1Nz4XPqcr7fKDNCvVjHsUvR2uYmuqFMw@mail.gmail.com> <20120211042121.B3653@besplex.bde.org> <20120211121947.M903@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11 February 2012 06:10, Bruce Evans <brde@optusnet.com.au> 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 <ed@80386.nl> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSOKpYH1U4_h1W8d5acb6JnwRGbVmz9zYo6S5JcCmVoDf7g>