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

Question 1

文件时间戳使用的时间是最后一次计时器计时的时间，该时间总是稍微过去一些。该current_time函数在inode.c来电ktime_get_coarse_real_ts64：

/**
 * current_time - Return FS time
 * @inode: inode.
 *
 * Return the current time truncated to the time granularity supported by
 * the fs.
 *
 * Note that inode and inode->sb cannot be NULL.
 * Otherwise, the function warns and returns time without truncation.
 */
struct timespec64 current_time(struct inode *inode)
{
    struct timespec64 now;

    ktime_get_coarse_real_ts64(&now);

    if (unlikely(!inode->i_sb)) {
        WARN(1, "current_time() called with uninitialized super_block in the inode");
        return now;
    }

    return timestamp_truncate(now, inode);
}

后者是的一部分记录如下的函数族:

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

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

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

除了修改内核之外，我不知道有什么方法可以完全避免这种情况。您可以通过增加来减少影响CONFIG_HZ。最近有一项建议来改进这一点，哪个仍在研究中。

Answer

文件时间戳使用的时间是最后一次计时器计时的时间，该时间总是稍微过去一些。该current_time函数在inode.c来电ktime_get_coarse_real_ts64：

/**
 * current_time - Return FS time
 * @inode: inode.
 *
 * Return the current time truncated to the time granularity supported by
 * the fs.
 *
 * Note that inode and inode->sb cannot be NULL.
 * Otherwise, the function warns and returns time without truncation.
 */
struct timespec64 current_time(struct inode *inode)
{
    struct timespec64 now;

    ktime_get_coarse_real_ts64(&now);

    if (unlikely(!inode->i_sb)) {
        WARN(1, "current_time() called with uninitialized super_block in the inode");
        return now;
    }

    return timestamp_truncate(now, inode);
}

后者是的一部分记录如下的函数族:

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

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

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

除了修改内核之外，我不知道有什么方法可以完全避免这种情况。您可以通过增加来减少影响CONFIG_HZ。最近有一项建议来改进这一点，哪个仍在研究中。

Question 2

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

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

// excerpt from the program linked above, not a relicensing
// …
    clock_gettime(CLOCK_REALTIME_COARSE, &now_coarse);
    clock_gettime(CLOCK_REALTIME, &now);
    int fd = open("temp", O_WRONLY | O_CREAT);
    write(fd, data, length);
    close(fd);
    clock_gettime(CLOCK_REALTIME, &now_after);

    stat("temp", &props);

    printf("Differences relative to coarse clock before:\n"
           "Fine Realtime before:   %+8jd ns\n"
           "File Modification Time: %+8jd ns\n"
           "Realtime clock after:   %+8jd ns\n",
           ns_difference(&now_coarse, &now),
           ns_difference(&now_coarse, &props.st_mtim),
           ns_difference(&now_coarse, &now_after));

产生类似的东西

Differences relative to coarse clock before:
Fine Realtime before:   +1551810 ns
File Modification Time:       +0 ns
Realtime clock after:   +1626199 ns

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

Differences relative to coarse clock before:
Fine Realtime before:   +1497562 ns
File Modification Time:  +999992 ns
Realtime clock after:   +1609943 ns

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

Total processed:     777618
Observed tick progressions:      10000
Percentage:                 0.013
Minimum tick delta:     999992
Maximum tick delta:     999993
Average tick delta: 999992.905900

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

Answer