bash EXT4 上的时间戳精度（亚毫秒）
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14392975/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
timestamp accuracy on EXT4 (sub millsecond)
提问by Wayne
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.
我在 Vala 中编写了一些代码，我将首先获取系统时间，然后创建一个文件，然后检索该文件的时间戳。时间戳总是比系统时间早，介于 500 到 1500 微秒之间，这是没有意义的。
I then wrote a simple shell script:
然后我写了一个简单的shell脚本：
while true; do
touch ~/tmp/fred.txt
stat ~/tmp/fred.txt|grep ^C
done
With the 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.
正如您所看到的，小数点后的前 3 位数字（毫秒）似乎没问题，因为它们按预期递增，但第 4 位及以后的数字看起来不正确。第 4 到第 9 位数字似乎正在缓慢倒计时。这有什么原因吗，因为我虽然 ext4 支持高达纳秒的精度。访问和修改时间戳的行为方式相同。
回答by Austin Phillips
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.
如果 inode 足够大以支持扩展时间信息（256 字节或更大），ext4 文件系统确实支持存储时间的纳秒分辨率。在您的情况下，由于分辨率大于第二个，因此这不是问题。
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.
在内部，ext4 文件系统代码调用current_fs_time()将当前缓存的内核时间截断为文件系统超级块中指定的时间粒度，ext4 为 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.
Linux 内核中的当前时间被缓存，通常只在定时器中断时更新。因此，如果您的计时器中断以 10 毫秒运行，则缓存时间将仅每 10 毫秒更新一次。当更新发生时，结果时间的准确性将取决于硬件上可用的时钟源。
Try this and see if you also get similar results to your stat calls:
试试这个，看看你是否也得到了与你的 stat 调用类似的结果：
while true; do date --rfc-3339=ns; done
On my machine (amd64, intel virtualbox) there is no quantization.
在我的机器（amd64，intel virtualbox）上没有量化。
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 datedoesn't really show anything for this situation. This is because datewill call the gettimeofdaysystem 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.
date对于这种情况，上面的检查使用并没有真正显示任何内容。这是因为date将调用gettimeofday系统调用，该调用将始终根据缓存的内核时间返回最准确的可用时间，如果可用，则由 CPU 周期时间调整以提供纳秒分辨率。然而，存储在文件系统中的时间戳仅基于缓存的内核时间。即最后一次定时器中断计算的时间。
