Re: Apparent backward time travel in timestamps on file creation

From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Howells <dhowells@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Apparent backward time travel in timestamps on file creation
Date: Thu, 30 Mar 2017 13:04:35 -0700	[thread overview]
Message-ID: <CA+55aFzUUU--ftUB_AE+fXsvwMdUKrGLrbiyVd97x_23eCx+DA@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFzW0P1ONajfgfmH93WgbPAirxurVHB1AaRxoGXEMK6LgQ@mail.gmail.com>

On Thu, Mar 30, 2017 at 12:52 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Mar 30, 2017 at 12:35 PM, David Howells <dhowells@redhat.com> wrote:
>>
>> Is there any way to determine the error bar, do you know?  Or do I just make
>> up a fudge factor?
>
> Hmm. The traditional error bar is just HZ

Oh, I'm just being stupid.

The error bar can be huge, for the simple reason that the filesystem
you are testing may not be sharing a clock with the CPU at _all_.

IOW, think network filesystems.

You basically should never test a file time with current time. Yes,
yes, you'd hope that people run NTP or other things and that clocks
are "close enough", but in general the only thing you should test a
file timestamp with is another file timestamp on the same filesystem.

I guess with NTP it's not unreasonable to still say "0.01s is a good
target". I remember having seen people whose clocks were off by *days*
(it shows up in SCM timestamps going backwards l^), but you'd hope
that is really really rare.

                 Linus