В дополнение к обычной системе ведения журналов, 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Вариант будет держать куст на переднем плане, так что вы увидите результаты в электронных хронах посылают вам. В противном случае, он будет работать в фоновом режиме, и вам придется помнить, чтобы проверить результаты вручную, поскольку они не будут в электронной почте.
Обновление : улучшен grep в соответствии с предложением Михаэля Кьёрлинга, спасибо.
Обновление 2 : Дополнительные примечания по сравнению с обычными операциями чтения (это относится не только к BTRFS):
Как указал Иоан, очистка может занять много часов, в зависимости от размера и типа массива (и других факторов), в некоторых случаях даже больше, чем день. И это активное сканирование, оно не будет обнаруживать будущие ошибки - цель скраба - найти и исправить ошибки на ваших дисках в тот момент. Но, как и в других системах RAID, рекомендуется планировать периодические очистки. Это правда, что типичная операция ввода-вывода, такая как чтение файла, действительно проверяет, действительно ли прочитанные данные верны. Но рассмотрим простое зеркало: если первая копия файла повреждена, возможно, из-за диска, который вот-вот умрет, но вторая копия, которая является правильной, фактически читается 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 отсутствует, т. Е. Больше не доступен ...