Я видел документацию по демону, который может выполнять программу/скрипт для различных событий 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
Итак, вы можете создать простое корневое задание cron:
[email protected]
@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 пометит такой диск как FAULTED). К сожалению, BTRFS может не распознать, что диск исчез, пока файловая система смонтирована, как указано в этой записи рассылки от 09/2015 (возможно, это было исправлено):
Разница в том, что у нас есть код для обнаружения отсутствия устройства при монтировании, но у нас нет кода (пока) для обнаружения его падения на смонтированной файловой системе. Почему надлежащее обнаружение исчезновения устройства не является приоритетом, я понятия не имею, но это отдельная проблема, не связанная с поведением монтирования.
https://www.mail-archive.com/[email protected]/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
Похоже на задачу для мониторинга системы. Существует проверка, которая реализует API плагина Nagios, которая называется:проверка_btrfs. Как вы можете видеть в исходном коде, у него есть функция, check_dev_statsкоторая проверяет статистику устройства и становится критической, если какое-либо из значений не равно нулю. Он также проверяет проблемы с распределением. Что остается неясным, так этокак ведет себя проверка, если один диск отсутствует или выходит из строя.
PS: Плагин упакован в Debian:мониторинг-плагины-btrfs