EXT4上的时间戳精度(亚毫秒)

我在Vala写了一些代码,首先得到系统时间,然后创build一个文件,然后检索该文件的时间戳。 时间戳将始终早于系统时间,在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位数字看起来并不正确。 第四到第九位数字似乎在做一个缓慢倒计时。 是否有任何理由,因为我虽然ext4支持纳秒精度。 访问和修改时间戳的行为方式相同。

如果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周期时间(如果可用,以提供纳秒分辨率)进行调整。 然而,存储在文件系统中的时间戳只是基于缓存的内核时间。 即在最后的定时器中断计算的时间。