У нас есть кастомная плата на базе BBB, у нее 256 МБ ОЗУ и 4 ГБ или eMMC. Мы используем Linux-3.12 и на eMMC у нас есть разделы ext4.
Я пишу скрипт, который периодически запускается и проверяет наличие ошибок файловой системы, и если разделы не смонтированы, я пытаюсь исправить ошибку с помощью e2fsck.
Изначально я использовал e2fsck -n /dev/mmcblk0pN (N is partition number)для проверки наличия ошибок в разделе файловой системы.
Однако указанная выше команда начала давать неправильный результат, когда раздел смонтирован и на нем создаются файлы.
Теперь мне нужна была альтернатива для проверки ошибок файловой системы.
Одним из вариантов является использование tune2fs -lкоманды для проверки Filesystem stateполя раздела.
Теперь я не уверен, является ли это поле надежным для проверки ошибок файловой системы или нет? И какие возможные значения может иметь это поле? Я видел его значения clean, clean with errorsно not cleanя не получаю больше информации из man-страницы.
Итак, tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”надежно ли обнаруживать ошибки файловой системы? Есть ли другой лучший вариант для проверки ошибок файловой системы в разделе?
Есть какие-нибудь предложения/указания/информация?
решение1
"Tune2fs -l" сообщит вам, заметило ли ядро проблемы с повреждением файловой системы во время работы. Например, если вы просите ext4 удалить файл, и ext4 обнаруживает, что некоторые блоки в этом файле уже были помечены как освобожденные, это означает, что битовая карта выделения повреждена. Обратите внимание, что битовая карта выделения была уже повреждена в то время, когда ext4 обнаружила ее. Фактически, она могла быть повреждена в течение нескольких дней или недель, и если вы записывали новые файлы, возможно, что ext4 могла выделить блоки для новых файлов, которые использовались для старых файлов, и пользователь мог потерять данные в результате.
Единственный способ достоверно сказать наверняка, является ли файловая система согласованной или может иметь некоторую степень повреждения, — запустить e2fsck на ней. Для этого требуется либо размонтировать файловую систему, либо создать снимок только для чтения. (Если вы используете LVM, вы можете создать снимок только для чтения, проверить снимок только для чтения, а затем, если файловая система окажется поврежденной, вы можете либо перезагрузить систему и позволить e2fsck исправить файловую систему, либо отправить электронное письмо системному администратору, чтобы запланировать время простоя для исправления файловой системы.)
При всем этом, если файловая система повреждена, то, скорее всего, это из-за аппаратной проблемы, как наиболее распространенного случая. Возможно, что это может быть из-за ошибки ядра, хотя я периодически запускаю регрессионные тесты на стабильных ядрах, а не только на upstream, и у нас не было проблем с повреждением fs очень долгое время. Возможно, что в драйвере устройства может быть ошибка повреждения памяти, и либо (a) драйвер устройства не upstream, и поставщик оборудования не провел надлежащий контроль качества, либо (b) ошибка была исправлена upstream и даже перенесена в последнее стабильное ядро, но ядро устройства не получало обновления из серии стабильных ядер.
Обратите внимание, что если вы хотите узнать, была ли файловая система повреждена из-за того, что ядро споткнулось о что-то явно неправильное, вам не нужно просто чистить dmesg или /var/log/messages. Вы также можете попробовать прочитать файл /sys/fs/ext4//first_error_time. Если этот файл содержит ненулевое значение, это скажет вам время (используя эпоху Unix), когда ядро обнаружило повреждение файловой системы. Файл errors_count в этом каталоге скажет вам, сколько повреждений файловой системы было обнаружено (но это может быть просто система, снова и снова спотыкающаяся об одну и ту же проблему). Также интересно, если вы хотите проверить, как ваша система обрабатывает ошибки файловой системы, обнаруживаемые ядром, вы можете попробовать записать строку в файл trigger_fs_error --- например, echo "test error" > /sys/fs/ext4/sda1/trigger_fs_error"
Наконец, взгляните на ручку поведения ошибок, которую вы можете установить в tune2fs. Возможно, если вы действительно хотите быть уверены, что не будет нанесен еще больший ущерб после обнаружения проблемы повреждения файловой системы, вы захотите настроить файловую систему на перемонтирование только для чтения при обнаружении проблемы --- или, может быть, просто принудительно перезагрузить, чтобы e2fsck можно было запустить во время последовательности загрузки для устранения проблемы до того, как (еще больше) пользовательских данных будут повреждены или потеряны.