主页 / unix / 问题 / 759880
Accepted
Alberto Pianon
Asked: 2023-10-26 17:06:44 +0800 CST

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

  • 772

在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 中得到相同的结果：

import os, time

def test():
    print(time.time())
    with open("test1", "w") as f:
        f.write("hello")
        print(os.stat("test1").st_mtime)

test()

1698255477.3125281
1698255477.3070245

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

def get_filesystem_time():
    """
    get the current filesystem time by creating a temporary file and getting
    its modification time.
    """
    with tempfile.NamedTemporaryFile() as f:
        return os.stat(f.name).st_mtime

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

linux

2 个回答

  1. Best Answer

    文件时间戳使用的时间是最后一次计时器计时的时间，该时间总是稍微过去一些。调用中的函数current_timeinode.cktime_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);
}

    后者记录如下：

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

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

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

    • 21

  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

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

    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

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

    • 14

相关问题