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

前一段时间，已经有一些关于ext4的讨论，它们可能会在不干净的卸载后留下空文件，本文对此进行了很好的总结。基本上，由于分配延迟，写操作可以在写缓存中保留的时间比ext日志的默认提交间隔（5秒）更长。

这些问题似乎已在修补程序中得到修复，该修补程序在某些情况下会强制分配块，从而默认情况下最多在5秒后将数据强制插入磁盘。

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

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

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

更新：我知道做正确的事情，即使用fsync（）时，所有这些都无关紧要。（这是所有有关ext4和数据丢失的讨论的主要原因-问题仅涉及应用程序未进行fsync（）处理或在适当的时候出现。）我不是在编写自己的应用程序，而是因为我我不知道我所有的应用程序是否都做对了，我想知道这种“危险”写入的大概时间。问的原因是我的图形驱动程序会定期导致内核崩溃，并且我想知道是否要担心最后5秒钟的数据写入。

您可以将提交间隔设置为自定义值，我认为该值可以高达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()适当使用的应用程序，那将尤其重要。

资料来源： 这里和个人经验

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

在保证暴露的EXT4文件系统的行为是“数据将在光盘成功后sync/ fsync呼叫”。因此，如果您有一个使您提出此问题的应用程序，则应在需要确保数据完整性的关键点插入同步调用。如果您担心相同的问题，则可以sync在执行任何可能会导致关机异常的危险行为之前调用命令行实用程序。