文件系统“提交间隔”选项如何与vm.dirty_expire_centisecs交互?当一个比另一个短的时候会发生什么?以不同的方式设置这些有意义吗?
我的理解是,文件系统提交间隔设置控制文件系统主动将脏数据和元数据写入磁盘的频率,即使应用程序尚未调用fsync。
另外,vm.dirty_expire_centisecs似乎具有类似的角色,但在VM层而不是文件系统层。
Ext4可以被告知每秒钟同步它的所有数据和元数据。默认值为5秒。这意味着,如果您失去了您的能力,您将失去与最近的5秒的工作(您的文件系统将不会被破坏,但由于日志)。
btrfscommit安装选项btrfscommit安装选项:
设置定期提交的间隔。较高的值将数据同步延迟到永久存储,在系统崩溃时会产生明显的后果。
注意,我现在忽略了XFS,因为它的fs.xfs.xfssyncd_centisecs选项似乎只适用于元数据。
此可调参数用于定义脏数据何时足够老,是否有资格由内核刷新线程写掉。它以百分之一秒表示。数据在内存中被脏的时间超过了这个间隔,下一次当刷新线程唤醒时,数据就会被写入。
发布于 2019-12-17 14:46:37
I 贴出这个问题 to linux-ext4 4@邮件列表,Jan Kara的回答是:
是的,效果相当相似,但并不完全相同。首先要注意的是一个明显的事实: ext4提交间隔只影响特定的文件系统,而dirty_expire_centisecs则影响全局写回对所有文件系统的行为。其次,提交间隔实际上是ext4传输的最大年龄。因此,如果日志中有元数据更改,则最迟在此之后将保持不变。所以说'mkdir‘,这将是持久的,最迟在这个时候。对于数据操作,事情要复杂得多。例如,当使用延迟分配时(这是默认的),更改只在写回期间记录在日记中。因此,它可以占用dirty_expire_centisecs从页面缓存写回数据,从而导致文件系统日志块分配等,然后它可以占用提交间隔,使这些更改成为持久的。因此,在这种情况下,间隔相加。在这两者之间还有其他一些特殊情况,但通常可以假定数据在dirty_expire_centisecs + commit_interval时间内自动持久。请注意,这两次实际上都是触发写回的时间,因此,如果磁盘太忙,数据完全在磁盘上的实际时间可能要高得多。
发布于 2019-05-04 11:12:40
它只是影响频率的实际逻辑是与内核。我不认为如果你给予更少的价值,它将是有效的,它采取内核默认值。
{
.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 */https://serverfault.com/questions/945936
复制相似问题