On Thu, Mar 30, 2017 at 10:30 AM, David Howells <dhowells@xxxxxxxxxx> 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
