问题
文件系统“提交间隔”选项如何与 交互vm.dirty_expire_centisecs
?当一个比另一个短时会发生什么?将它们设置为不同是否有意义?
我的理解是,文件系统提交间隔设置控制文件系统主动将脏数据和元数据写入磁盘的频率,即使fsync
应用程序尚未调用。
单独来看,vm.dirty_expire_centisecs
似乎具有类似的作用,但是在 VM 层而不是文件系统层。
参考
可以指示 Ext4 每“nrsec”秒同步一次其所有数据和元数据。默认值为 5 秒。这意味着如果您断电,您将丢失最多最近 5 秒的工作(但由于日志记录,您的文件系统不会受损)。
设置定期提交的间隔。较高的值会推迟将数据同步到永久存储,当系统崩溃时会产生明显的后果。
注意,我暂时不考虑 XFS,因为它的fs.xfs.xfssyncd_centisecs
选项似乎仅适用于元数据。
此可调参数用于定义脏数据何时足够旧,可供内核刷新线程写出。它以百分之一秒表示。内存中脏数据超过此间隔的时间将在下次刷新线程唤醒时写出。
答案1
我发布了这个问题到linux-ext4@ 邮件列表,而 Jan Kara 的回答是:
是的,效果相当相似,但并不完全相同。首先要注意的一个显而易见的事实是,ext4 提交间隔仅影响特定文件系统,而 dirty_expire_centisecs 则影响所有文件系统的全局写回行为。
其次,提交间隔实际上是 ext4 事务的最大期限。因此,如果日志中有待处理的元数据更改,它将最迟在此时间之后变为持久的。因此,对于“mkdir”,它将最迟在此时间之后变为持久的。对于数据操作,事情更加复杂。例如,当使用延迟分配(这是默认设置)时,更改仅在写回期间记录在日志中。因此,从页面缓存写回数据可能需要 dirty_expire_centisecs,这会导致文件系统日志记录块分配等,然后可能需要提交间隔才能使这些更改变为持久的。因此,在这种情况下,间隔加起来。中间还存在其他特殊情况,但通常可以合理地假设数据在 dirty_expire_centisecs + commit_interval 时间内自动持久化。请注意,这两个时间实际上是触发写回的时间,因此如果磁盘太忙,数据完全写入磁盘的实际时间可能会高得多。
答案2
它只会影响内核的实际逻辑频率。我认为如果你给出的值较小,它不会有效,它会采用内核默认值。
{
.procname = "dirty_expire_centisecs",
.data = &dirty_expire_interval,
.maxlen = sizeof(dirty_expire_interval),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
.extra1 = &zero,
}
当 inode 中的第一个页面被弄脏时,当前时间会记录在 inode 中。当此时间超过 dirty_expire_centisecs 时,inode 中的所有脏页都会被写入。因此,考虑到这种机制,您描述的行为在我看来是意料之中的。
unsigned int dirty_expire_interval = 30 * 100; /* centiseconds */