文件系统“提交间隔”选项如何交互vm.dirty_expire_centisecs？当其中一个比另一个短时会发生什么？以不同的方式设置这些是否有意义？
我的理解是，文件系统提交间隔设置控制文件系统主动将脏数据和元数据写入磁盘的频率，即使fsync应用程序尚未调用也是如此。
单独来看，vm.dirty_expire_centisecs似乎有类似的作用，但在 VM 层而不是文件系统层。
Ext4 可以被告知每隔“nrsec”秒同步其所有数据和元数据。默认值为 5 秒。这意味着，如果您断电，您将丢失最近 5 秒的工作（不过，由于日志功能，您的文件系统不会被损坏）。
设置定期提交的时间间隔。较高的值会推迟将数据同步到永久存储，从而在系统崩溃时产生明显的后果。
请注意，我暂时忽略 XFS，因为它的fs.xfs.xfssyncd_centisecs选项似乎仅适用于元数据。
此可调参数用于定义脏数据何时足够旧，可以由内核刷新器线程写出。它以百分之一秒表示。内存中脏数据的时间超过此时间间隔的数据将在下次刷新器线程唤醒时被写出。
我将这个问题发布到linux-ext4@ 邮件列表，Jan Kara 的回答是：
是的，效果很相似，但又不完全相同。首先要观察的是一个明显的事实，即 ext4 提交间隔仅影响特定文件系统，而 dirty_expire_centisecs 影响所有文件系统上的全局写回行为。
其次，提交间隔实际上是 ext4 事务的最大年龄。因此，如果日志中存在未决的元数据更改，那么它最迟会在该时间之后变得持久。因此，对于“mkdir”来说，它最迟在这个时间之后将持续存在。对于数据操作来说事情更加复杂。例如，当使用延迟分配（这是默认设置）时，更改仅在写回期间记录在日志中。因此，从页面缓存写回数据可能需要 dirty_expire_centisecs 时间，这会导致文件系统日志块分配等，然后可能需要提交间隔才能使这些更改持久化。所以在这种情况下，间隔相加。中间还有其他特殊情况，但通常可以合理地假设数据在 dirty_expire_centisecs + commit_interval 时间内自动持久化。请注意，这两个时间实际上都是触发写回的时间，因此如果磁盘太忙，数据完全存储在磁盘上的实际时间可能会长得多。