为什么 Linux 中的文件系统时间总是比系统时间晚一些毫秒？

Question

在Linux中，文件系统时间似乎总是落后系统时间几毫秒，如果您想检查文件是否在给定时间之前或之后在非常窄的时间范围（毫秒）内被修改，则会导致不一致。

在任何具有支持纳秒分辨率的文件系统的 Linux 系统中（我尝试使用具有 256 字节 inode 和 ZFS 的 ext4），如果您尝试执行以下操作：

date +%H:%M:%S.%N; echo "hello" > test1; stat -c %y test1 | cut -d" " -f 2

第二个输出值（文件修改时间）始终比第一个输出值（系统时间）晚几毫秒，例如：

17:26:42.400823099
17:26:42.395348462

而它应该是相反的，因为文件在调用命令后被test1修改。date

你可以在 python 中得到相同的结果：

date +%H:%M:%S.%N; echo "hello" > test1; stat -c %y test1 | cut -d" " -f 2

1698255477.3125281
1698255477.3070245

为什么会这样，有没有办法避免它，使系统时间与文件系统时间一致？到目前为止，我发现的唯一解决方法是通过创建一个虚拟临时文件并获取其修改时间来获取文件系统“时间”（无论这在实践中意味着什么），如下所示：

17:26:42.400823099
17:26:42.395348462

但我想知道是否有更清洁的解决方案。

Answer 1

文件时间戳使用的时间是最后一次计时器计时的时间，该时间总是稍微过去一些。调用中的函数current_timeinode.cktime_get_coarse_real_ts64：

\n

/**\n * current_time - Return FS time\n * @inode: inode.\n *\n * Return the current time truncated to the time granularity supported by\n * the fs.\n *\n * Note that inode and inode->sb cannot be NULL.\n * Otherwise, the function warns and returns time without truncation.\n */\nstruct timespec64 current_time(struct inode *inode)\n{\n    struct timespec64 now;\n\n    ktime_get_coarse_real_ts64(&now);\n\n    if (unlikely(!inode->i_sb)) {\n        WARN(1, "current_time() called with uninitialized super_block in the inode");\n        return now;\n    }\n\n    return timestamp_truncate(now, inode);\n}\n

\n

后者是记录如下的一系列函数的一部分：

\n

\n

这些比非粗略版本更快，但不太准确，对应于用户空间CLOCK_MONOTONIC_COARSE并CLOCK_REALTIME_COARSE在用户空间中，以及用户空间中不可用的等效 boottime/tai/raw 时基。

\n

这里返回的时间对应于最后一个计时器滴答声，可能是过去 10 毫秒（对于 CONFIG_HZ=100），与读取“jiffies”变量相同。这些[函数]仅在快速路径中调用时才有用，并且人们仍然期望优于秒的精度，但不能轻松使用“jiffies”，例如用于 inode 时间戳。在具有可靠周期计数器的大多数现代机器上，跳过硬件时钟访问可节省大约 100 个 CPU 周期，但在具有外部时钟源的旧硬件上最多可节省几微秒。

\n

\n

请注意 inode 时间戳的具体提及。

\n

I\xe2\x80\x99m 不知道有什么方法可以完全避免这种情况，除非修改内核。您可以通过增加 来减少影响CONFIG_HZ。最近有一项改进建议，目前仍在研究中。

\n

Answer 2

斯蒂芬·基特的回答似乎很准确。

\n

我们可以通过实际获得文件系统使用的相同“粗略”时钟来很好地重现这一点，至少在我的内核配置上是如此；在访问文件之前始终获取粗略实时时钟的C程序要么采用文件的时间戳，要么（很少）采用早一个系统时钟周期的时间戳：

\n

// excerpt from the program linked above, not a relicensing\n// \xe2\x80\xa6\n    clock_gettime(CLOCK_REALTIME_COARSE, &now_coarse);\n    clock_gettime(CLOCK_REALTIME, &now);\n    int fd = open("temp", O_WRONLY | O_CREAT);\n    write(fd, data, length);\n    close(fd);\n    clock_gettime(CLOCK_REALTIME, &now_after);\n\n    stat("temp", &props);\n\n    printf("Differences relative to coarse clock before:\\n"\n           "Fine Realtime before:   %+8jd ns\\n"\n           "File Modification Time: %+8jd ns\\n"\n           "Realtime clock after:   %+8jd ns\\n",\n           ns_difference(&now_coarse, &now),\n           ns_difference(&now_coarse, &props.st_mtim),\n           ns_difference(&now_coarse, &now_after));\n

\n

产生类似的东西

\n

Differences relative to coarse clock before:\nFine Realtime before:   +1551810 ns\nFile Modification Time:       +0 ns\nRealtime clock after:   +1626199 ns\n

\n

now_coarse前面提到的大约tick-duration delta的情况很少发生，当系统tick正好落在文件的获取和修改之间时，就会发生这种情况：

\n

Differences relative to coarse clock before:\nFine Realtime before:   +1497562 ns\nFile Modification Time:  +999992 ns\nRealtime clock after:   +1609943 ns\n

\n

顺便说一句，统计数据表明，如果我们执行上述操作，直到收集到 10,000 次发生这种“滴答跳”的事件，则可能的延迟范围非常小：

\n

Total processed:     777618\nObserved tick progressions:      10000\nPercentage:                 0.013\nMinimum tick delta:     999992\nMaximum tick delta:     999993\nAverage tick delta: 999992.905900\n

\n

换句话说，当涉及到报价之间的增量时，我们的时间安排非常接近。

\n