`e2fsck -n` + как узнать, нужно ли запускать e2fsck для исправления поврежденных блоков?

Мы хотим проверить файловую систему на дисках как /deb/sdc... /dev/sdg на каждой машине Red Hat Linux.

Цель состоит в том, чтобы найти, какие диски требуют e2fsck (как e2fsck -y /dev/sdb так далее.)

Согласно справочной странице

-n
Откройте файловую систему только для чтения и примите ответ "нет" на все вопросы. Позволяет e2fsck использоваться не в интерактивном режиме. Эта опция не может быть указана одновременно с -p или же -y опции.

Когда мы запускаем команду (пример)

 e2fsck -n /dev/sdXX

мы получаем

e2fsck 1.42.9 (28-Dec-2013)
Warning!  /dev/sdc is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sdc: clean, 94/1310720 files, 156685/5242880 blocks

Так что нам нужно захватить из e2fsck -n вывод, который требует от нас запустить e2fsck (без -n)?

процесс e2fsck

init 1
umount /dev/sdXX
e2fsck -y /dev/sdXX  # (or e2fsck -C /dev/sdXX for full details) 
init 3
Источник

2 ответа

Решение

Ты используешь e2fsck поэтому я предполагаю, что мы говорим о ext? файловая система. Команда

tune2fs -l /dev/sdXX

скажет вам очевидное состояние файловой системы (которая может быть смонтирована, это безопасно). Вы получите (среди прочего) либо

Filesystem state:   clean

или что-то еще, чем clean, Так как grep возвращает false, если совпадение не найдено, ваша основная попытка может быть такой:

tune2fs -l /dev/sdXX | grep "^Filesystem state:[ ]*clean$" || { commands; to; fix; the; filesystem; }

Вышеуказанное будет работать, только если файловая система заранее обнаружит свое нечистое состояние. Иногда вы все равно хотите проверить наличие проблем (вот почему fsck каждый N-й маунт или когда прошло столько-то дней). Если я вас правильно понимаю, вы пытаетесь узнать, следует ли вам e2fsck -y /dev/sdXX, анализируя выход e2fsck -n /dev/sdXX,

Я говорю не анализировать вывод. Проверьте статус выхода. Увидеть man 8 e2fsck учить:

Код выхода, возвращаемый e2fsck это сумма следующих условий:
0 - нет ошибок
1 - Исправлены ошибки файловой системы
2 - Исправлены ошибки файловой системы, система должна быть перезагружена
4 - Ошибки файловой системы не исправлены
8 - Операционная ошибка
16 - Ошибка использования или синтаксиса
32 - e2fsck отменено по запросу пользователя
128 - Ошибка общей библиотеки

Заметка e2fsck -n /dev/sdXX не будет делать ничего полезного (и вернет "нет ошибок"), если файловая система кажется чистой; так что это еще один способ обнаружить текущее видимое состояние, как мы сделали с tune2fs, Для проверки в любом случае вам нужно -f вариант. Затем вы хотите знать, включает ли статус выхода 4, В bash это можно сделать с помощью:

e2fsck -nf /dev/sdXX  # this is safe even if the filesystem is mounted
status=$?
[ $(( $status & 4 )) -eq 4 ] && { commands; to; fix; the; filesystem; }

Быстрое объяснение:

  • $? является статусом выхода последней команды (e2fsck в этом случае). Я сохраняю его в отдельной переменной, чтобы можно было выполнить несколько тестов с ним. Это не обязательно в этом простом примере, где есть только один тест, но в целом это хорошая практика. Основная причина: после этих строк $status по-прежнему содержит статус выхода e2fsck и может быть повторно использован, пока (новый) $? не имеет ничего общего с e2fsck,
  • $(( ... )) делает арифметику оболочки
  • где & побитовое И,
  • затем [ ... -eq 4 ] на самом деле test Команда, чтобы проверить, если результат 4,
  • Если тест пройден успешно, то { ... } блок будет выполнен.

Возможны ошибки не в самой файловой системе, а на более глубоком уровне устройства. Я думаю, что это выходит за рамки этого вопроса, но просто чтобы указать вам правильное направление, если вам это нужно, это полезные команды (обратите внимание, sdX не sdXX):

  • smartctl -t long /dev/sdX
  • badblocks -n -b 512 /dev/sdX

Прочитайте их справочные страницы, прежде чем использовать их.

Источник

Сначала проверьте, является ли это файловой системой журналирования.

"Журналируемая файловая система - это файловая система, которая отслеживает изменения, еще не зафиксированные в основной части файловой системы, записывая намерения таких изменений в структуре данных, известной как" журнал ", которая обычно представляет собой циклический журнал. В случае сбоя системы или сбоя питания такие файловые системы могут быть быстрее подключены к сети с меньшей вероятностью повреждения ".

Затем вы можете попробовать Gparted для проверки согласованности и посмотреть, что инструмент может сделать для вас.

Источник
Другие вопросы по тегам