В дополнение к обычной системе ведения журналов, 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 отсутствует, т. Е. Больше не доступен ...
