Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934652AbdC3StN (ORCPT ); Thu, 30 Mar 2017 14:49:13 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:36134 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934395AbdC3StM (ORCPT ); Thu, 30 Mar 2017 14:49:12 -0400 MIME-Version: 1.0 In-Reply-To: <22214.1490895007@warthog.procyon.org.uk> References: <22214.1490895007@warthog.procyon.org.uk> From: John Stultz Date: Thu, 30 Mar 2017 11:49:09 -0700 Message-ID: Subject: Re: Apparent backward time travel in timestamps on file creation To: David Howells Cc: Thomas Gleixner , Linus Torvalds , lkml , "linux-fsdevel@vger.kernel.org" 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: 1477 Lines: 39 On Thu, Mar 30, 2017 at 10:30 AM, David Howells wrote: > Hi Thomas, John, > > I've been writing a testcase for xfstests to test statx. However, it's turned > up what I think is a bug in the kernel's time-tracking system. If I do: > > date +%s.%N > touch foo > dump-timestamps foo > > such that foo is created, sometimes the atime, mtime and ctime timestamps on > foo will be *before* the time printed by 'date'. > > For example: > > [root@andromeda ~]# Z=/b/zebra6; date +%s.%N; touch $Z; /tmp/dump-timestamps $Z > 1490894656.267225764 > st_atime: 1490894656.267032686 > st_mtime: 1490894656.267032686 > st_ctime: 1490894656.267032686 > > As can be seen, the three file timestamps are -193078 nsec from the prior > clock time. This was with git commit: Linus covered this already, as its a granularity difference, but it is something that seems to crop up every few years. If you want a timestamp that matches the granularity of what the filesystem uses, you can use clock_gettime(CLOCK_REALTIME_COARSE,..), which returns the same "time-at-the-last-tick" that filesystem timestamps use (with the same performance benefit). Though one slight correction to Linus' comment is that both filesystem timestamps and CLOCK_REALTIME_COARSE are NTP corrected, the main performance gain is that one doesn't have go out and read the clocksource and covert the cycles to nanoseconds. thanks -john