timestamp accuracy on EXT4 (sub millsecond)

Question

I was writing some code in Vala where I would first get the system time, then create a file, then retrieve the time stamp of that file. The timestamp would always be earlier that the system time, somewhere between 500 and 1500 micro seconds which didn't make sense.

I then wrote a simple shell script:

while true; do
touch ~/tmp/fred.txt
stat ~/tmp/fred.txt|grep ^C
done

With the following result:

Change: 2013-01-18 16:02:44.290787250 +1100
Change: 2013-01-18 16:02:44.293787250 +1100
Change: 2013-01-18 16:02:44.296787250 +1100
Change: 2013-01-18 16:02:44.298787248 +1100
Change: 2013-01-18 16:02:44.301787248 +1100
Change: 2013-01-18 16:02:44.304787248 +1100
Change: 2013-01-18 16:02:44.306787248 +1100
Change: 2013-01-18 16:02:44.309787248 +1100
Change: 2013-01-18 16:02:44.312787248 +1100
Change: 2013-01-18 16:02:44.315787248 +1100

As you can see the first 3 digits after the decimal point (milli seconds) seem ok as they are incrementing as expected, but the 4th digit and beyond does not look right. The 4th to 9th digits seems to be doing a slow count down instead. Is there any reason for this as I though ext4 supports up to the nano second in precision. The Access and Modify timestamps behave in the same way.

Answer 1

The ext4 file system does support nanosecond resolution on stored times if the inodes are big enough to support the extended time information (256 bytes or larger). In your case, since there is greater than second resolution, this is not a problem.

Internally, the ext4 filesystem code calls current_fs_time() which is the current cached kernel time truncated to the time granularity specified in the file system's superblock which for ext4 is 1ns.

The current time within the Linux kernel is cached, and generally only updated on a timer interrupt. So if your timer interrupt is running at 10 milliseconds, the cached time will only be updated once every 10 milliseconds. When an update does occur, the accuracy of the resulting time will depend on the clock source available on your hardware.

Try this and see if you also get similar results to your stat calls:

while true; do date --rfc-3339=ns; done

On my machine (amd64, intel virtualbox) there is no quantization.

eg

2013-01-18 17:04:21.097211836+11:00
2013-01-18 17:04:21.098354731+11:00
2013-01-18 17:04:21.099282128+11:00
2013-01-18 17:04:21.100276327+11:00
2013-01-18 17:04:21.101348507+11:00
2013-01-18 17:04:21.102516837+11:00

Update:

The above check using date doesn't really show anything for this situation. This is because date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt.