Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934890AbdC3UEk (ORCPT ); Thu, 30 Mar 2017 16:04:40 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:33837 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933493AbdC3UEh (ORCPT ); Thu, 30 Mar 2017 16:04:37 -0400 MIME-Version: 1.0 In-Reply-To: References: <22214.1490895007@warthog.procyon.org.uk> <23410.1490902528@warthog.procyon.org.uk> From: Linus Torvalds Date: Thu, 30 Mar 2017 13:04:35 -0700 X-Google-Sender-Auth: onEXu70aONny_DycNM5hnAhxaDw Message-ID: Subject: Re: Apparent backward time travel in timestamps on file creation To: David Howells Cc: Thomas Gleixner , John Stultz , Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1050 Lines: 27 On Thu, Mar 30, 2017 at 12:52 PM, Linus Torvalds wrote: > On Thu, Mar 30, 2017 at 12:35 PM, David Howells 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