Question

我在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支持高达纳秒级的精度。访问和修改时间戳的行为方式相同。

Answer 1

如果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

<强>更新：

使用date的上述检查并未真正显示此情况。这是因为date将调用gettimeofday系统调用，它将始终根据缓存的内核时间返回最准确的可用时间，并根据CPU周期时间（如果可用）调整以提供纳秒分辨率。但是，存储在文件系统中的时间戳仅基于缓存的内核时间。即在最后一次计时器中断时计算的时间。

EXT4上的时间戳精度（亚毫秒）

1 个答案: