9

我在 Vala 中编写了一些代码，我将首先获取系统时间，然后创建一个文件，然后检索该文件的时间戳。时间戳总是早于系统时间，介于 500 到 1500 微秒之间，这是没有意义的。

然后我写了一个简单的shell脚本：

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

结果如下：

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

如您所见，小数点后的前 3 位数字（毫秒）似乎没问题，因为它们按预期递增，但第 4 位及以后的数字看起来不正确。第 4 位到第 9 位数字似乎在进行缓慢的倒计时。是否有任何理由，因为我虽然 ext4 支持高达纳秒的精度。访问和修改时间戳的行为方式相同。

4

1 回答 1

16

如果 inode 足够大以支持扩展时间信息（256 字节或更大），则 ext4 文件系统确实支持存储时间的纳秒分辨率。在您的情况下，由于分辨率大于第二个，因此这不是问题。

在内部，ext4 文件系统代码调用current_fs_time()将当前缓存的内核时间截断为文件系统超级块中指定的时间粒度，对于 ext4 为 1ns。

Linux 内核中的当前时间被缓存，并且通常只在定时器中断时更新。所以如果你的定时器中断运行在 10 毫秒，缓存的时间只会每 10 毫秒更新一次。当确实发生更新时，结果时间的准确性将取决于硬件上可用的时钟源。

试试这个，看看你是否也得到与统计调用类似的结果：

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

在我的机器（amd64，intel virtualbox）上没有量化。

例如

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

更新：

对于这种情况，上述检查 usingdate并没有真正显示任何内容。这是因为date将调用gettimeofday系统调用，该调用将始终根据缓存的内核时间返回最准确的可用时间，如果可用，则通过 CPU 周期时间进行调整以提供纳秒级分辨率。然而，存储在文件系统中的时间戳仅基于缓存的内核时间。即最后一次定时器中断计算的时间。

于 2013-01-18T06:06:29.827 回答