«Tune2fs -l» сообщит вам, замечало ли ядро проблемы с повреждением файловой системы во время работы. Например, если вы просите ext4 удалить файл, а ext4 обнаруживает, что некоторые блоки в этом файле уже помечены как освобожденные, это означает, что битовая карта выделения повреждена. Обратите внимание, что растровое изображение allocaiton уже было повреждено в тот момент, когда ext4 обнаружило его. Фактически, он мог быть поврежден в течение нескольких дней или недель, и если бы вы писали новые файлы, возможно, что ext4 мог бы выделить блоки для новых файлов, которые использовались для более старых файлов, и пользователь мог потерять данные как результат.
Единственный способ достоверно сказать, является ли файловая система непротиворечивой или может иметь некоторое повреждение, - запустить на ней e2fsck. Для этого необходимо либо отключить файловую систему, либо создать моментальный снимок только для чтения. (Если вы используете LVM, вы можете создать снимок только для чтения, проверить снимок только для чтения, а затем, если обнаружено, что файловая система повреждена, вы можете либо перезагрузить систему и позволить e2fsck исправить файловую систему, или отправьте электронное письмо системному администратору, чтобы запланировать время простоя для исправления файловой системы.)
При этом, если файловая система повреждена, скорее всего, из-за проблемы с оборудованием, как наиболее распространенного случая. Возможно, это может быть из-за ошибки в ядре, хотя я периодически запускаю регрессионные тесты на стабильных ядрах, а не только в апстриме, и у нас не было проблемы с повреждением fs в течение очень долгого времени. Вполне возможно, что в драйвере устройства произошла ошибка повреждения памяти, а либо (а) драйвер устройства не подключен к исходному потоку, а поставщик оборудования не выполнил надлежащий контроль качества, либо (б) ошибка была исправлена в восходящем потоке и даже подтолкнул к последнему стабильному ядру, но ядро устройства не получало обновления из серии стабильных ядер.
Обратите внимание, что если вы ищете, не обнаружена ли файловая система поврежденной, потому что ядро споткнулось о что-то явно неправильное, вам не нужно просто очищать dmesg или / var / log / messages. Вы также можете попробовать прочитать файл / sys / fs / ext4 // first_error_time. Если этот файл содержит ненулевое значение, это сообщит вам время (с использованием эпохи Unix), когда ядро обнаружило повреждение файловой системы. Файл errors_count в этом каталоге скажет вам, сколько повреждений файловой системы было обнаружено (но это может быть просто повторное срабатывание системы из-за одной и той же проблемы). Также интересно, если вы хотите проверить, как ваша система обрабатывает ошибки файловой системы, обнаруживаемые ядром, вы можете попробовать записать строку в файл trigger_fs_error - например, echo "test error">
Наконец, взгляните на ручку поведения ошибок, которую вы можете установить в tune2fs. Возможно, если вы действительно хотите убедиться, что после обнаружения проблемы с повреждением файловой системы больше ущерба не будет, вам нужно настроить файловую систему так, чтобы она перемонтировалась только для чтения при обнаружении проблемы --- или, может быть, просто принудительно перезагрузите компьютер, чтобы e2fsck мог быть запущен во время последовательности загрузки, чтобы исправить проблему до того, как (даже больше) пользовательские данные будут повреждены или потеряны.