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

Way*_*yne 9 linux bash ext4

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

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

while true; do
touch ~/tmp/fred.txt
stat ~/tmp/fred.txt|grep ^C
done
Run Code Online (Sandbox Code Playgroud)

具有以下结果:

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
Run Code Online (Sandbox Code Playgroud)

正如您所看到的那样,小数点后的前3位数(毫秒)似乎正常,因为它们按预期递增,但第4位及以上的数字看起来并不正确.第4到第9位数似乎是慢慢倒数.有没有任何理由,因为我虽然ext4支持高达纳秒级的精度.访问和修改时间戳的行为方式相同.

Aus*_*ips 13

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

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

Linux内核中的当前时间被缓存,并且通常仅在定时器中断时更新.因此,如果您的定时器中断以10毫秒运行,则缓存时间将仅每10毫秒更新一次.发生更新时,结果时间的准确性取决于硬件上可用的时钟源.

试试这个,看看你是否也得到了与你的stat调用类似的结果:

while true; do date --rfc-3339=ns; done
Run Code Online (Sandbox Code Playgroud)

在我的机器上(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
Run Code Online (Sandbox Code Playgroud)

更新:

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

  • 如果它很重要,请更改ext4内核代码.我怀疑使用缓存时间是因为读取缓存非常快.在计算文件系统时间时,以更差的性能为代价,改变纳秒分辨率可能很容易.http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf,第219页以后对内核计时器系统进行了一些深入的讨论.没有直接关系,但提供了一些背景. (2认同)