小编典典

EXT4的时间戳准确度(毫秒)

linux

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


阅读 374

收藏
2020-06-07

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

2020-06-07