Как контролировать рейд файловой системы 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 опция будет держать скраб на переднем плане, так что вы увидите результаты в электронном письме, которое отправляет вам cron. В противном случае, он будет работать в фоновом режиме, и вам придется помнить, чтобы проверить результаты вручную, поскольку они не будут в электронной почте.

Обновление: улучшен grep в соответствии с предложением Михаэля Кьёрлинга, спасибо.

Обновление 2: Дополнительные примечания по сравнению с обычными операциями чтения (это относится не только к BTRFS):
Как указал Иоан, очистка может занять много часов, в зависимости от размера и типа массива (и других факторов), в некоторых случаях даже больше, чем день. И это активное сканирование, оно не будет обнаруживать будущие ошибки - цель скраба - найти и исправить ошибки на ваших дисках в тот момент. Но, как и в других системах RAID, рекомендуется планировать периодические очистки. Это правда, что типичная операция ввода-вывода, такая как чтение файла, действительно проверяет, действительно ли прочитанные данные верны. Но рассмотрим простое зеркало - если первая копия файла повреждена, возможно, на диске, который вот-вот умрет, но вторая копия, которая является правильной, фактически читается BTRFS, тогда BTRFS не будет знать, что существует повреждение на одном из дисков. Это просто потому, что запрошенные данные были получены, они совпадают с контрольной суммой, сохраненной BTRFS для этого файла, поэтому BTRFS не нужно читать другую копию. Это означает, что даже если вы специально прочитали файл, который, как вы знаете, поврежден на одном диске, нет гарантии, что эта операция чтения обнаружит повреждение.
Теперь давайте предположим, что BTRFS только когда-либо читает с хорошего диска, не выполняется очистка, которая бы выявила повреждение на плохом диске, а затем хороший диск тоже испортился - результатом была бы потеря данных (по крайней мере, BTRFS знал бы какие файлы все еще правильны и все еще позволят вам прочитать те). Конечно, это упрощенный пример; на самом деле, BTRFS не всегда читает с одного диска и игнорирует другой.
Но дело в том, что периодические операции очистки важны, потому что они будут находить (и исправлять) ошибки, которые не обязательно обнаруживаются обычными операциями чтения.

Неисправные диски. Поскольку этот вопрос довольно популярен, я хотел бы отметить, что это "решение по мониторингу" предназначено для выявления проблем с, возможно, неисправными дисками (например, умирающий диск вызывает ошибки, но все еще доступен).

С другой стороны, если диск внезапно пропал (отсоединен или полностью мертв, а не умирает и выдает ошибки), это будет неисправный диск (ZFS пометит такой диск как ОШИБКА). К сожалению, BTRFS может не осознавать, что диск отключен во время монтирования файловой системы, как указано в записи списка рассылки от 09/2015 (возможно, это было исправлено):

Разница в том, что у нас есть код для обнаружения устройства, отсутствующего при монтировании, у нас нет кода (пока), чтобы обнаружить его падение в смонтированной файловой системе. Почему правильное обнаружение исчезновения устройства не является приоритетом, я понятия не имею, но это отдельная проблема от поведения монтирования.

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

Похоже, задача для мониторинга системы. Существует проверка, которая реализует API подключаемого модуля Nagios, которая называется: check_btrfs. Как вы можете видеть в исходном коде, он имеет функцию под названием check_dev_stats которая проверяет статистику устройства и становится критической, если любое из значений не равно нулю. Он также проверяет наличие проблем с распределением. Остается неясным, как ведет себя проверка, если один диск отсутствует или отключается.

PS: плагин упакован в Debian: monitor-plugins-btrfs