为什么kjournald在大多数静止的文件系统上非常活跃？

Question

注意:这是一个“记录我的过程”的问题，我将写一个答案。幸运的是，服务器故障已经帮助我解决了这个问题，因为把我的情况写下来以便其他人能够评估它，让我意识到正在发生的事情。

1. 我在Debian服务器上使用ext3文件系统。
2. 尽管在我的主文件系统上很少发生与文件有关的活动，但是kjournald (通过iotop看到)仍然有大量的活动。
3. 这个活动是周期性的爆发，使我的总体平均写入量提高到大约2MB/秒(这是我非常关心的，因为我想得到一些SSD，而且这个速率实际上足以严重威胁到当前模型非常慷慨的写入能力)。
4. 我已经用noatime,nodiratime安装了有问题的文件系统。
5. 我已经将文件系统的日志提交间隔从5秒增加到300秒。

怎么一回事？(剧透者:这是一个用户空间的问题。我写这篇文章主要是为了突出可能违反直觉的潜在问题。)

Answer 1

请注意，在此服务器上运行的主要应用程序管理一个非常大的、人口稠密的目录树，并以某种程度上不太理想的所有权和权限在该树中写入文件。因为让应用程序更改它是相当讨厌的，而且文件需要相当快地修复它们的所有权和权限(有些延迟很好，但不是很多)，所以我设置了一个cron作业，每分钟在大型的、人烟稠密的目录树上抛出大量的chown -R和chmod -R。在这段时间里，一切似乎都很顺利，所以我说，enh，这太过分了，但很有效，我会接受的。

然而。结果是，当您执行chown或chmod时，不管是否发生任何更改，它都会注册可日志的ext文件系统元数据。因此，文件系统上几乎没有任何变化，但是产生了大量的元数据，当日志提交时，这些元数据就会被敲出磁盘。糟了。

因此，我将chown和chmod更改为find作业，这些作业实际上是在更改文件之前查找需要更改的文件，平均写入量从2MB/S增加到大约50 kB/s。