如何监视BTRFS文件系统RAID中的错误？

我看到了有关守护程序的一些文档，该守护程序可以为各种BTRFS事件执行程序/脚本，但现在找不到了。

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

除了常规的日志记录系统外，BTRFS还具有stats命令，该命令可跟踪每个驱动器的错误（包括读取，写入和损坏/校验和错误）：

# 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

因此，您可以创建一个简单的根cronjob：

MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

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

此外，对于BTRFS之类的高级文件系统（具有校验和），通常建议每两周安排一次清理，以检测由不良驱动器引起的无提示损坏。

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

该-B选项将使Scrub保持在前台，以便您在cron发送给您的电子邮件中看到结果。否则，它将在后台运行，您将不得不记住手动检查结果，因为它们不会出现在电子邮件中。

更新：MichaelKjörling建议改进grep，谢谢。

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

有故障的驱动器：由于这个问题非常普遍，因此我想指出，此“监视解决方案”用于检测可能损坏的驱动器的问题（例如，死于驱动器的驱动器会导致错误，但仍然可以访问）。

另一方面，如果驱动器突然消失（断开连接或完全死掉而不是死亡和产生错误），则可能是驱动器出现故障（ZFS会将此类驱动器标记为FAULTED）。不幸的是，正如09/2015的邮件列表中所指出的那样，BTRFS可能没有意识到在挂载文件系统时驱动器已消失（可能已对其进行了修补）：

区别在于我们有代码来检测挂载时不存在的设备，我们还没有代码（尚未）来检测挂载的文件系统中是否存在设备。为什么正确检测设备消失似乎不是优先事项，我不知道，但这是与挂载行为分开的问题。

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html

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

从btrfs-progs v4.11.1开始，stats具有--check选项，如果任何一个值都不为零，该选项将返回非零值，从而消除了对正则表达式的需要。

设备统计信息-c /

我不会依赖stats命令来进行错误通知，因为如果驱动器突然消失，此命令将不返回任何错误。您可以通过断开sata电缆或拉动驱动器的方式进行测试-不建议在重要的文件系统中使用。

btrfs device stats /

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

btrfs fi show

似乎没有正式报告BTRFS事件以供用户处理的守护程序或实用程序。最接近的替代方法是监视系统日志中是否有来自BTRFS的消息并做出相应的反应。

http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html

上面的链接提供了有关配置脚本（secDebian或SEC上的软件包）的更多详细信息，该脚本旨在用于通用日志监视，以处理有关BTRFS的意外日志消息。这也取决于定期对文件系统进行清理，以检查是否发生位腐烂并发出日志条目，这是一种先发制人的措施。以下是特定于SEC脚本的摘录：

如何配置秒，事件相关器以报告btrfs文件系统错误或警告

安装sec.pl后（在debian或http://simple-evcorr.sourceforge.net/上apt-get install sec ），安装下面的2个配置文件。

这不是万无一失的，它依赖于已知消息的正则表达式，并且可以报告所有未知消息。您可以根据需要扩展前瞻性否定正则表达式。

polgara:~\# cat /etc/default/sec  
\#Defaults for sec  
RUN_DAEMON="yes"  
DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/syslog -pid=/var/run/sec.pid -detach -log=/var/log/sec.log"

polgara:~# cat /etc/sec.conf  
\# http://simple-evcorr.sourceforge.net/man.html  
\# http://sixshooter.v6.thrupoint.net/SEC-examples/article.html  
\# http://sixshooter.v6.thrupoint.net/SEC-examples/article-part2.html  
type=SingleWithSuppress  
ptype=RegExp  
pattern=(?i)kernel.*btrfs: (?!disk space caching is enabled|use ssd allocation|use .* compression|unlinked .* orphans|turning on discard|device label .* devid .* transid|detected SSD devices, enabling SSD mode|has skinny extents|device label|creating UUID tree|checking UUID tree|setting .* feature flag|bdev.* flush 0, corrupt 0, gen 0)  
window=60  
desc=Btrfs unexpected log  
action=pipe '%t: $0' /usr/bin/mail -s "sec: %s" root

听起来像是系统监视任务。存在一个实现Nagios插件API的检查，称为：check_btrfs。如您在源代码中所看到的，它具有一个称为的函数，该函数check_dev_stats检查设备统计信息，并且如果任何一个值都不为零，则将变得至关重要。它还检查分配问题。尚不清楚的是，如果一个磁盘不存在或脱机，检查的行为如何。

PS：该插件打包在Debian中：Monitoring-plugins-btrfs