☰

如何监控 BTRFS 文件系统错误？

tag-icon • tag-icon linux raid events btrfs
如何监控 BTRFS 文件系统错误？

我看到了一些关于可以为各种 BTRFS 事件执行程序/脚本的守护进程的文档，但我再也找不到它了。

如何在 BTRFS raid1 阵列的驱动器发生故障时执行脚本/程序？我想在任何错误上运行脚本，作为潜在故障驱动器的早期警告，但实际驱动器故障才是最重要的。我想在那时卸载文件系统（如果这不是 BTRFS 所做的）并设置警报。

答案1

除了常规的日志系统之外，BTRFS 还有一个统计数据命令，跟踪每个驱动器的错误（包括读取、写入和损坏/校验和错误）：

# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs   0
[/dev/mapper/luks-123].read_io_errs    0
[/dev/mapper/luks-123].flush_io_errs   0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0

因此你可以创建一个简单的 root cronjob：

[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

这将每小时检查一次错误计数，并向您发送电子邮件。显然，您会测试这种情况（例如，通过造成损坏或删除 grep）以验证电子邮件通知是否有效。

此外，对于像 BTRFS 这样的高级文件系统（具有校验和功能），通常建议每隔几周安排一次清理，以检测由坏驱动器导致的静默损坏。

@monthly /sbin/btrfs scrub start -Bq /data

该-B选项将使清理保持在前台运行，这样你就可以在 cron 发送给你的电子邮件中看到结果。否则，它将在后台运行，你必须记住手动检查结果，因为它们不会出现在电子邮件中。

更新：按照 Michael Kjörling 的建议改进了 grep，谢谢。

更新 2：关于清理与常规读取操作的附加说明（这不仅适用于 BTRFS）：
正如 Ioan 所指出的，清理可能需要几个小时，具体取决于阵列的大小和类型（以及其他因素），在某些情况下甚至需要超过一天的时间。而且它是一种主动扫描，不会检测未来的错误 - 清理的目标是在当时找到并修复驱动器上的错误。但与其他 RAID 系统一样，建议安排定期清理。确实，典型的 I/O 操作（如读取文件）会检查读取的数据是否正确。但请考虑一个简单的镜像 - 如果文件的第一个副本已损坏，可能是由即将损坏的驱动器损坏，但第二个副本是正确的，实际上是由 BTRFS 读取的，那么 BTRFS 将不知道其中一个驱动器上有损坏。这只是因为请求的数据已收到，它与 BTRFS 为该文件存储的校验和相匹配，因此 BTRFS 无需读取另一个副本。这意味着，即使您专门读取一个您知道在一个驱动器上已损坏的文件，也不能保证该读取操作能够检测到该损坏。
现在，让我们假设 BTRFS 只从好的驱动器读取，没有运行任何可以检测坏驱动器损坏的清理程序，然后好驱动器也坏了 - 结果将是数据丢失（至少 BTRFS 会知道哪些文件仍然正确并且仍然允许您读取这些文件）。当然，这是一个简化的示例；实际上，BTRFS 不会总是从一个驱动器读取而忽略另一个驱动器。
但关键是定期清理很重要，因为它们会发现（并修复）常规读取操作不一定能检测到的错误。

故障驱动器：由于这个问题很常见，我想指出的是，这种“监控解决方案”用于检测可能有问题的驱动器（例如，坏掉的驱动器导致错误但仍然可以访问）。

另一方面，如果驱动器突然消失（断开连接或完全死机，而不是死机并产生错误），则该驱动器将出现故障（ZFS 会将此类驱动器标记为 FAULTED）。不幸的是，BTRFS 可能无法意识到在文件系统挂载时驱动器已消失，正如 2015 年 9 月的邮件列表条目中指出的那样（可能已修补此问题）：

不同之处在于，我们有代码来检测挂载时不存在的设备，但我们还没有代码来检测挂载文件系统上是否存在设备。我不知道为什么正确检测设备消失似乎不是优先事项，但这是与挂载行为无关的问题。

https://www.mail-archive.com/[电子邮件保护]/msg46598.html

到那时，dmesg 中将出现大量错误消息，因此 grepping dmesg 可能不可靠。
对于使用 BTRFS 的服务器，可能有一个想法是进行自定义检查（cron 作业），如果 RAID 阵列中至少有一个驱动器消失，即不再可访问，则发送警报...

答案2

从 btrfs-progs v4.11.1 开始，stats 具有 --check 选项，如果任何值不为零，它将返回非零，从而无需使用正则表达式。

device stats -c /

答案3

我不会依赖 stats 命令来获取错误通知，因为如果驱动器突然消失，此命令不会返回任何错误。您可以通过断开 SATA 电缆或拔出驱动器来测试它 - 对于重要的文件系统不建议这样做。

btrfs device stats /

重新启动后，btrfs 显示缺少驱动器，但可能为时已晚。

btrfs fi show

答案4

听起来像是一个系统监控任务。有一个实现 Nagios 插件 API 的检查，名为：检查btrfs。正如您在源代码中看到的，它有一个名为的函数check_dev_stats，用于检查设备状态，如果任何值不为零，它将变为临界值。它还会检查分配问题。尚不清楚的是如果某个磁盘缺失或脱机，检查将如何进行。

PS:该插件在Debian中打包：监控插件-btrfs

相关内容