ext4 可以将文件系统写入缓存多长时间？

Question

前段时间，有一些关于 ext4 在不干净的卸载后可能留下空文件的讨论，这篇文章总结得很好。基本上，由于延迟分配，写入可以在写入缓存中保留比 ext 日志的默认提交间隔（5 秒）更长的时间。

这些问题似乎已在一个补丁中得到解决，该补丁在某些情况下强制分配块，从而默认情况下最多 5 秒后强制数据到磁盘。

我想知道当应用程序覆盖文件的现有部分而不截断或附加文件本身时会发生什么。是否也会在 5 秒内强制写入磁盘？

这似乎与追加到文件的情况不同：追加时，文件大小发生变化，这是元数据的变化；因此，需要在 5 秒内提交日志，并且由于 data=ordered，出于安全考虑，必须在此之前写入数据（否则其他用户的已删除文件的一部分可能会显示给附加文件的所有者）文件）。

当只是覆盖文件数据时，没有理由必须在元数据日志提交之前进行数据写入，因为旧数据与新数据属于同一用户。那么写入是否发生在提交之前，或者是否可以延迟比日志提交间隔更长的时间？如果有，多长时间？

更新：我知道所有这些在做正确的事情时都是无关紧要的，即使用 fsync()。（这是所有关于 ext4 和数据丢失的讨论的主要原因——问题只涉及应用程序而不是 fsync()ing，或者不是在正确的时刻。）我不是在写我自己的应用程序，我问是因为我不知道我的所有应用程序是否都做正确的事情，我想知道这种“危险”写入的大致时间范围。问的原因是我的显卡驱动经常导致kernel panic，我想知道我是否需要担心超过最后5秒的数据写入。

Answer 1

您可以将提交间隔设置为自定义值，我相信该值可以高达 32 位无符号整数秒；所以大约 40 亿秒，或 136 年。这可以通过commitmount 选项获得，您可以按如下方式使其生效（这只是一个示例；您也可以在 中设置fstab）：

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

提交间隔不基于任何类型的条件，例如数据是否被附加或覆盖现有数据或其他任何类型。的commit（如果你不提供在所有的安装选项，默认为5秒）安装选项相当于在bash shell做这样的事情：

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

不要混淆data=ordered和这个全局文件系统同步间隔（对于我们这些了解命令行程序功能的人来说，“提交间隔”可能是一个意义不大的术语sync，在这种情况下，最好将其命名为“同步间隔”）。data=ordered是关于数据和元数据更新的顺序（data=writeback“不太安全/更快”和data=journal“更安全/更慢”）。commit=12345678是关于文件系统驱动程序本身强制将所有脏数据/日志/元数据/任何内容完全同步到物理媒体的频率。如果您愿意，您当然可以将其设置为 136 年，并安装data=writeback,nobh不调用fsync()或sync()将在 RAM 中放置脏页的程序...

更新：根据您在问题编辑中的上下文，我会说您应该使用挂载选项data=journal,commit=1或什sync至使用挂载选项运行文件系统，直到您能够解决图形驱动程序内核恐慌。这将保持最大的数据完整性，但以性能为代价。如果您经常将不能丢失的数据写入磁盘，您将特别想要这样做，如果您不“信任”您正在使用的应用程序，这将更加重要fsync()。

来源： 这里和个人经验

Answer 2

无论你的问题的答案是什么，都没关系。

ext4 文件系统保证公开的行为是“成功sync/fsync调用后数据将存储在光盘上”。因此，如果您有一个应用程序让您提出这个问题，您应该在需要确保数据完整性的关键点插入同步调用。如果您是担心同样问题的用户，您可以sync在执行任何可能导致不正常关闭的危险行为之前调用命令行实用程序。