使用外部日志时禁用 ext4 写屏障

Question

我目前正在尝试不同的方法来使用快速 NVMe 设备提高 Debian 上相当大的、基于旋转磁盘的软件突袭 (mdadm) 阵列的写入速度。

我发现使用一对这样的设备（raid1，镜像）来存储文件系统的日志会产生有趣的性能优势。我用来实现这一点的安装选​​项是noatime,journal_aync_commit,data=journal.

在我的测试中，我还发现添加该barrier=0选项在写入性能方面提供了显着的好处。但是，我不确定在我的特定文件系统配置中使用此选项是否安全。这是内核文档关于 ext4 写屏障的说明：

写屏障强制对日志提交进行适当的磁盘排序，使易失性磁盘写入缓存可以安全使用，但会降低一些性能。如果您的磁盘以一种或另一种方式由电池供电，则禁用屏障可以安全地提高性能。

我使用的特定 NVMe 设备是Intel DC P3700，它具有内置断电保护功能，这意味着在意外关机的情况下，由于储备能量，临时缓冲区中仍然存在的任何数据都可以安全地提交到 NAND 存储贮存。

所以我的问题是，如果日志存储在具有电池后备缓存的设备上，而文件系统的其余部分本身位于没有此功能的磁盘上，我是否可以安全地禁用 ext4 写屏障？

Answer 1

我正在写一个新答案，因为经过进一步分析，我认为以前的答案不正确。

如果我们查看该write_dirty_buffers函数，它会发出带有标志的写入请求REQ_SYNC，但不会导致发出缓存刷新或屏障。这是通过blkdev_issue_flush 调用来完成的，该调用通过对标志的验证进行适当的门控JDB2_BARRIER，该标志本身仅在启用屏障的情况下安装文件系统时才存在。

因此，如果我们回顾一下checkpoint.c，只有当交易从日志中删除时，障碍才重要。代码中的注释在这里提供了丰富的信息，告诉我们这个写屏障不太可能是必要的，但无论如何都是作为一种保护措施存在的。我认为这里的假设是，当事务从日志中删除时，数据本身不太可能仍然徘徊在驱动器的缓存中，并且尚未提交到永久存储。但由于这只是一个假设，因此无论如何都会发出写屏障。

那么，为什么在将数据写入主文件系统时不使用屏障呢？我认为这里的关键是，只要日志是一致的，文件系统中丢失的元数据（例如，因为它在断电事件中丢失）通常会在日志重播期间恢复，从而避免文件系统损坏。此外，使用data=journal还应该保证实际文件系统数据的一致性，因为据我了解，恢复过程还将写出作为重播机制一部分提交给日志的数据块。

因此，虽然 ext4 实际上不会在检查点结束时刷新磁盘缓存，但应采取一些步骤来最大限度地提高断电情况下的可恢复性：

1. 文件系统应该使用data=journal, 而不是data=writeback（data=ordered使用外部日志时不可用）来安装。这一点应该是显而易见的：我们想要日志中所有传入数据块的副本，因为这些数据块可能会在断电事件中丢失。这在性能方面并不昂贵，因为 NVMe 设备速度非常快。

2. 应使用最大日志大小 102400 块（使用 4K 文件系统块时为 400MB），以便最大限度地提高日志重放中可恢复的数据量。这应该不是问题，因为所有 NVMe 设备的大小始终至少为几 GB。

3. 如果在写入密集型操作期间发生意外关闭，仍然可能会出现问题。如果事务从日志设备删除的速度快于数据驱动器自行刷新缓存的速度，则可能会发生不可恢复的数据丢失或文件系统损坏。

因此，在我看来，底线是禁用写屏障并不是 100% 安全，尽管可以实施一些预防措施（#1 和 #2）以使此设置更安全一些。