☰

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

tag-icon • tag-icon filesystems ext4
使用 ext4 可以将文件系统写入缓存多长时间？

前段时间，有人讨论过 ext4 在未彻底卸载后可能会留下空文件，总结得很好在本文中基本上，由于延迟分配，写入可以在写入缓存中保留比 ext journal 的默认提交间隔（5 秒）更长的时间。

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

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

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

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

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

答案1

您可以将提交间隔设置为自定义值，我相信，该值可以高达 32 位无符号整数秒数；因此大约为 40 亿秒，即 136 年。这可以通过 mount 选项实现commit，您可以按如下方式实施（这仅仅是一个示例；您也可以在 中设置它fstab）：

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

提交间隔不基于任何类型的条件，例如数据是否被附加或覆盖现有数据等。commitmount 选项（如果您根本不提供 mount 选项，则默认为 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 中的程序......几个生命周期。

更新：根据您在问题编辑中的上下文，我认为您应该使用 mount 选项data=journal,commit=1甚至syncmount 选项来运行文件系统，直到您能够解决图形驱动程序内核崩溃问题。这将保持最大的数据完整性，但会以牺牲性能为代价。如果您经常将数据写入您无法承受丢失的磁盘，那么您尤其需要这样做，如果您不“信任”您正在使用的应用程序并无法fsync()正确使用，那么这一点就显得尤为重要。

来源： 这里以及个人经历

答案2

不管你的问题的答案是什么，这都不重要。

这保证暴露ext4 文件系统的行为是“成功执行sync/fsync调用后数据将保存在磁盘上”。因此，如果您的应用程序让您产生此疑问，则应在需要确保数据完整性的关键点插入同步调用。如果您是担心相同问题的用户，您可以在sync执行可能导致非正常关机的任何危险行为之前调用命令行实用程序。

相关内容