На додаток до звичайної системи ведення журналів, 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
Таким чином, ви можете створити просту кореневу роботу:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Це дозволить перевіряти позитивні підрахунки помилок щогодини та надсилатиме вам електронне повідомлення. Очевидно, ви перевірили б такий сценарій (наприклад, викликавши корупцію або видаливши греп), щоб перевірити, чи працює повідомлення електронною поштою.
Крім того, для вдосконалених файлових систем, таких як BTRFS (у яких є контрольна сума), часто рекомендується планувати скраб кожні пару тижнів, щоб виявити мовчазне пошкодження, спричинене поганим приводом.
@monthly /sbin/btrfs scrub start -Bq /data
Цей -Bваріант дозволить зберегти скраб на передньому плані, так що ви побачите результати в електронному листі, який вам надсилає. В іншому випадку він працюватиме у фоновому режимі, і вам доведеться пам’ятати, щоб перевірити результати вручну, оскільки їх не було в електронній пошті.
Оновлення : покращений греп, як запропонував Майкл Кьорлінг, дякую.
Оновлення 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 було б багато повідомлень про помилки, тож отримання тексту dmesg може бути не надійним.
Для сервера, що використовує BTRFS, може бути ідеєю встановити спеціальну перевірку (завдання cron), яка надсилає попередження, якщо принаймні один з накопичувачів у RAID-масиві відсутній, тобто вже недоступний ...