Давайте рассмотрим, что делать в следующей гипотетической ситуации. Вы
работаете в вашей линуксовой консоли, делаете вызов приложения или
обращение к файлу с данными, при этом Linux внезапно замирает при
попытке чтения диска. Затем, на экран (или на консоль) выползает
следующее:
Seek error accessing /dev/hda6 at block 52146, IDE reset (successful).
Через некоторое время, потраченное на попытки обращения к диску, Linux
продолжает свою работу. Если вам посчастливилось, все запущенное вами
работает без каких либо проблем. Если же нет, ваша программа может не
запуститься, либо в вашем файле данных будет мусор.
Шансы на попадание в описанную выше ситуацию увеличиваются, если вы
используете жесткий диск, которому уже несколько лет. Вы начинаете
время от времени замечать ошибки обращения к диску. Начиная с этого
момента можно дать безошибочный прогноз, что с течением времени
ваш диск будет работать все хуже и хуже. Поэтому вам просто необходимо
срочно предпринять для исправления ситуации некоторые действия. Многие
производители жестких дисков предоставляют утилиты для нахождения и
фиксирования дефектных секторов на жестком диске. К большому сожалению,
эти утилиты также уничтожают всю информацию на вашем диске и нормально
работают исключительно из под DOS, а для Linux их не предусмотрено.
К счастью, в Linux есть набор системных утилит, которые помогут вам
при работе с родным для Linux форматом файловой системы ext2. (Утилиты
также доступны в minix. Если вам необходимо восстанавливать
работоспособность файловых систем, не являющихся для Linux родными, вы
должны использовать собственный комплект утилит для этих файловых
систем). Несмотря на то, что эти утилиты не имеют столь дружественного
интерфейса, как Norton Disk Doctor или Microsoft ScanDisk, они
выполняют фактически ту же работу. В этой статье мы рассмотрим, как
пользоваться некоторыми утилитами для решения проблемы, описанной в
самом начале. Остальные утилиты для работы с диском могут быть найдены
в /sbin и /usr/sbin, но без них вполне можно обойтись.
А сейчас давайте заставим жесткий диск работать правильно.
Перед тем, как начать, убедитесь, что вы используете ядра 2.0.х
совместно с дисками IDE, при этом проверьте, установлены ли исправления
ядра системы. Если вы не знаете, на каком чипсете построен ваш
компьютер, безопасно будет откомпилировать ядро с опциями CMD640,
RZ1000 и Intel 82371. Эти опции можно найти в разделах Floppy, ID and
other block devices в команде make config. Это позволит в будущем
сохранить ваши данные. Пакеты исправлений ошибок необходимы вам в любом
случае, однако они могут не оказывать никакого влияния на проверку
вашего жесткого диска.
Я не люблю патриотических призывов, однако вынужден иногда их
изрекать. Невозможно обойтись без того, чтобы сказать, что вы всегда
должны делать резервные копии системы и ваших данных, и именно этот
момент - самое время заняться тем, чтобы создать архив вашей системы на
другом носителе. Некоторые ваши действия, особенно если их выполнить
неправильно, могут частично или полностью разрушить файловую систему
или некоторые из важных файлов - будьте же внимательны и потом не
говорите, что я вас не предупреждал.
Подготовка
Теперь, когда вы действительно защитили все ваши данные, можно
начать. Наиболее безопасный путь начала - запустить полную проверку
файловой системы. На моей системе - а это комбинация Red Hat (я обожаю
загрузку в стиле SYSVinit) и Slackware - я нахожу fsck -
программу-оболочку, которая определяет тип файловой системы на
устройстве из /etc/fstab, а затем запускает соответствующую
этой файловой системе
fsck.filesystemtype - в моем случае fsck.ext2. Вы можете
непосредственно запустить e2fsck или же произвести запуск в форме
fsck.ext2. Не парьтесь, это один и тот же файл. Один из них является
всего лишь символьной ссылкой на другой.
Перед тем, как начать, давайте подготовим вашу систему к той работе,
которая ей предстоит. В любое время, когда я выполняю низкоуровневое
обслуживание системы, я нахожу правильным отключить ее от сети. Обычно
это обеспечивается переходом в однопользовательский режим. Вы можете
делать некоторые из тестов на init level 2 (без сетевых подключений),
но следите за тем, чтобы в памяти было как можно меньше процессов,
занимающихся записью на диск, и ни одного - запущенного с раздела,
который вы подвергаете проверке. Однопользовательский режим для таких
действий идеален. Простая команда telinit 1 переведет систему в
однопользовательский режим.
Если вы проверяете не корневую файловую систему, отмонтируйте ее,
перед тем как начать какие-либо действия. Если вы забудете это сделать,
fsck напомнит вам, что система монтирована, и спросит, надо ли
продолжать проверку. Ответьте "No" - запуск низкоуровневой диагностики,
в процессе которой происходят операции записи на диск в обход средств
операционной системы, в то время как файловая система смонтирована,
является очень плохой идеей.
Безусловно, вы не можете размонтировать корневую файловую систему.
Ее можно перемонтировать в состояние "только для чтения", однако баг
команды mount не всегда позволяет это сделать. Если необходимо
произвести проверку корневой файловой системы, вы можете
перезагрузиться в однопользовательском режиме с разделами,
монтированными read-only, путем использования ключа -b в
командной строке LILO. Ключ -b передается LILO в init и
приведёт к аварийной загрузке, при которой не запускаются стартовые
скрипты. Если вас всегда удивляло, кто и когда создает различные
разделы - например, для /usr и /home и ограничивает
размер и структуру корневого раздела - теперь вы это знаете.
fsck - проверка файловой системы
Вызов fsck из командной строки на каком либо разделе обычно не
означает, что проверка будет в действительности запущена, поскольку вы
не достигли требуемого значения счетчика количествамонтирований.
Тем не менее, система считает, что файловая система находится в
нормальном состоянии и в проверке не нуждается. Для того, чтобы
принудительно запустить проверку, вызовите fsck с ключем -f.
Начиная с этого момента, может произойти две вещи: fsck корректно
запустится и проверит ваш дисковый раздел (возможно, при проверке
вызвав на экран очередную лавину сообщений об ошибках) или же завершит
свою работу с сообщением об ошибке. Если fsck не запускается, вы
получите от этой программы дополнительную информацию, представленную
вам в виде сообщения об ошибке. Обычно наиболее общая информация,
которую вы должны передать e2fsck - это адрес альтернативного
суперблока или размер блока, по которому e2fsck может вычислить, где
находится альтернативный суперблок. Ключ -b заставляет e2fsck использовать
альтернативный суперблок, но вам придется подсказать e2fsck, где его
найти. На файловых системах ext2 суперблоки обычно размещаются на 8193,
16385 и больших множителях 8192+1 (см. разъяснения к программе
dumpe2fs, ниже). В качестве альтернативного решения, вы можете передать
e2fsck размер блока с ключем -B
(если у вас, конечно, есть такая информация), для того, чтобы позволить
e2fsck вычислить расположение альтернативного суперблока. Далее я
сообщу, где именно получить значение размера блока, если оно вам
понадобится.
Здесь следует упомянуть два взаимоисключающих ключа, доступных для
fsck и e2fsck. Первый ключ - это -n,
который заставляет fsck не отвечать на какие-либо запросы и оставит
файловую систему в оригинальном состоянии, без исправления каких-либо
ошибок. Второй ключ -y,
который приводит к автоматической коррекции любых найденных ошибок.
Обычно, для ускорения процесса, вы можете запускать fsck с ключем -y. Так почему бы не использовать
эту опцию постоянно? Я категорически предостерегаю вас от такого
подхода, если вы подозреваете проблемы с файловой системой. В то время
как fsck еще не обнаружила проблем, ввести в командной строке fsck -y и отвлечься на чашечку
кофе, оставив машину заботиться о себе самостоятельно, чрезвычайно
неосмотрительный поступок. Если, в интересах скорости, вы используете
автоматический ответ "yes" на все запросы, проверяйте время от времени
содержимое каталогов lost+found. Кроме того, не помешает записать
номера блоков и inode, появляющиеся на экране во время запуска fsck,
чтобы в дальнейшем проверить, не относятся ли они к какому-нибудь файлу.
Другие доступные опции для fsck и e2fsck могут быть найдены на
страницах руководства man. Я нахожу, что man pages для fsck и e2fsck
весьма неплохо написаны, что вполне соответствует важности этих утилит
для поддержания хорошего состояния вашей системы.
Некоторые общие сообщения fsck
Вам могут встретиться сообщения, спрашивающие, позволить или нет
fsck исправить ошибку. Ответ "no" обычно завершает программу чтобы вы
могли фиксировать проблему и заново запустить fsck. Однако, большинство
сообщений об ошибках представляют собой уведомление о какой-либо
несущественной проблеме, и вы можете безопасно отвечать "yes" на них.
Когда вы видите сообщение такое как inode 1234 unattached, оно
означает, что файл, на который указывает inode (информационный
указатель) 1234 has, по неизвестной причине, потерял своё имя. Это
может случиться по различным причинам, включая сбой по питанию или
перезагрузку компьютера без должной синхронизации диска.
Другие распространённые ошибки - это inodes с нулевым временем,
которые также означают, что диск не был синхронизирован перед
выключением. Если вы часто наблюдаете такие ошибки и всегда правильно
выключаете систему, то можете обнаружить и другие проблемы. В этом
случае, вам надо начать с проверки разъёмов питания и коммуникационных
кабелей, а также блока питания вашего компьютера на стабильность
выходного напряжения и уровень помех по питанию. Напоследок проверьте
параметры вашего жесткого диска. Я должен предупредить, что изменение
параметров диска по умолчанию может привести к серьёзным повреждениям
файловой системы или разрушению файлов - будьте предельно осторожны.
Каталоги lost+found
Один каталог lost+found обязательно должен находиться в корневом
разделе каждой файловой системы. Если у вас, для примера,
смонтировано две файловых системы, /usr и /home, у вас
должно быть три каталога lost+found. Эти каталоги содержат inodes,
которые были отсоединены от их файловых имен. Файлы в этих
каталогах имеют вид ./#nnnn, где nnnn - номер inode,
используемой в качестве имени файла. Вы можете определить, что это за
файл, используя команду cat. Если вывод команды cat
представляет собой мусор, у вас скорее всего двоичный файл. В этом
случае, вы можете применить chmod +x #nnnn, и затем запустить
файл. Эти процедуры дадут вам достаточное количество информации по
поводу файла. Если файл окажется важным для вас, он может быть
переименован и перемещен в другое местоположение; в ином случае его
можно удалить.
Вывод дампа файловой системы
Следующая утилита, на которую необходимо обратить внимание, это
dumpe2fs. Чтобы вызвать
эту утилиту, напечатайте dumpe2fs
device, и вы получите информацию о группе блоков
для указанного вами устройства device. Как обычно, вы получите гораздо
больше информации, чем вам требуется, но если вы понимаете физическую
структуру файловой системы, вывод будет для вас
понятен.
В действительности нам надо первые 22 строки вывода. (Самая первая
строка - номер версии, не является частью выводимой таблицы).
Большинство из этих строк разъясняют себя сами; однако, одна или две
потребуют дальнейших разъяснений. Самая первая строка представляет
собой "магическое число" файловой системы. Это число не случайно - оно
всегда 0xEF53 для файловых систем ext2. Префикс 0x
идентифицирует число как шестнадцатиричное. Сигнатура
EF53 обычно означает Расширенную файловую систему - Extended
Filesystem версии (EF) и модификации 53. Однако, мне неясно, почему это
число именно 53. (Оригинальные версии ext2fs имеют последними цифрами
51 и несовместимы с текущей версией). Вторая строка указывает состояние
файловой системы - clean или unclean. Файловая система, которая была
должным образом синхронизирована и размонтирована, будет помечена как clean.
Файловая система, которая в настоящее время смонтирована в режиме
записи/чтения или не была должным образом синхронизирована перед
отключением (например, из-за пропадания питания или аппаратной
перезагрузки компьютера), будет помечена как not clean.
Указатель not clean приведет к автоматическому включению fsck
при нормальной загрузке системы.
Другой важной для нас строкой является счетчик блоков (он нам
понадобится позже), который показывает, какое количество блоков
занимает раздел. Мы будем использовать это число в командах e2fsck и
badblocks. Однако, я и так знаю, сколько блоков занимает каждый раздел;
я это вижу всякий раз при вызове команды df для проверки
свободного пространства на моём диске. (Если бы это было игровое шоу,
здесь должен зазвучать малиновый колокольчик). Сверьтесь с выводом
команд df и dumpe2fs - цифры будут теми же самыми. Счетчик блоков в
dumpe2fs - это единственное, что нам надо. df предоставляет нам число
1024-кб блоков, к которым мы можем иметь доступ в той или иной форме.
Суперблоки, например, не входят в это значение. Да и сумма "used" и
"available" составляет ли собой общее число 1024-кб блоков?
Это противоречие появляется потому что, по умолчанию система
резервирует приблизительно пять процентов блоков. Это процентное
соотношение может быть изменено, как и многие другие параметры,
перечисленные в первых 22 строка вывода команды dumpe2fs, но опять же,
без должного понимания того, что вы делаете, избегайте этим заниматься.
Таким образом, информация, которую вы видите в результате работы
команды dumpe2fs, является трансляцией на английский язык информации из
первого суперблока раздела. Копии суперблока также содержатся в
границах каждой группы для целей резервирования. Значение Blocks
per group представляет собой смещение для каждого суперблока.
Первый начинается с единицы, следующие размещаются на кратном
расстоянии значения Blocks per group плюс 1.
Хоть мы и не будем использовать больше первых 22 строк информации,
быстро пробежаться взглядом по остатку листинга может быть полезным.
Информация сгруппирована по блокам и отражает, как ваш диск организован
для хранения данных. Суперблоки как либо специально не обозначаются, но
это те самые первые два блока, которые всегда пропускаются с начала
каждой группы. Битовая карта блоков - это простая карта,
показывающая использование блоков в группе. Эта карта содержит нули или
единицы, соответствующие использованным или пустым блокам,
соответственно, в группе. Битовая карта inode (информационных узлов)
похожа на битовую карту блоков, но соответствует inod'ам в группе.
Таблица инодов является перечнем инодов. Следующая строка показывает
число свободных блоков. Обратите внимание, что некоторые группы не
имеют свободных блоков, но зато все имеют свободные иноды
badblocks
Теперь, когда мы имеем всю необходимую информацию, мы можем запустить программу
badblocks. Эта утилита выполняет сканирование поверхности с целью поиска дефектов.
Минимальная командная строка для запуска:
badblocks /dev/device
device является именем устройства, которое мы
собираемся проверять (hda1, sda1, итд.) и
blocks-count то самое значение, которое мы получили после
запуска dumpe2fs (см. выше).
Для badblocks доступны четыре опции. Первая опция -b с величиной блока в
виде аргумента. Эта опция необходима только в том случае, когда fsck не запускается или
неверно определяет размер блока. Вторая опция -o, аргументом которой является имя файла,
инициирует запись в файл номера блоков, содержащих дефектные области. Если эта опция не указана,
перечень дефектных блоков будет выведен на консоль (stdout). Третья опция
-v для многословного вывода (самодокументирования). Последняя опция: -w, которая уничтожит
все данные на вашем диске путем перезаписи каждого блока и сверки записанного. (Опять же, об этом вы
будете предупреждены.)
Самым лучшим будет запустить badblocks с опцией -o filename. После того, как дефектные
блоки будут найдены, они будут записаны в файл в виде номеров, по одному на строке.
Этот файл очень пригодится в дальнейшем. Чтобы запустить badblocks с такой опцией, файловая
система, куда будет выводиться файл результатов, должна быть смонтирована с разрешением записи.
Все действия выполняются от пользователя root. badblocks производит запись файла в текущий каталог,
до тех пор, пока в имени файла не будет указан полный путь. Если вам надо смонтировать корневой
рездел с разрешением записи, для того чтобы записать этот файл, воспользуйтесь командой
mount -n -o remount,rw /.
Как только вы получите список номеров дефектных блоков, вам необходимо проверить,
используются ли эти блоки каким-либо файлом, и если нет - сделать их используемыми.
Если блок уже маркирован как "используемый", вы наверняка захотите вывести этот блок из
применения (данные, приходящиеся а блок, скорее всего кажутся разрушенными), и
переустановить его статус в "allocated". Распечатайте список дефектных блоков - он
пригодится позднее.
Последняя утилита, которую мы обсудим, является наиболее мощной и опасной.
С помощью команды debugfs вы можете модифицировать диск методом прямой записи.
Поскольку эта утилита обладает такой мощью, вы должны обычно запускать её
в режиме "только для чтения" до тех пор, как вы действительно будете готовы
применить изменения и записать их на диск. Чтобы вызвать debugfs в режиме
"только для чтения", не надо использовать какие-либо ключи. Для перехода в
режим "чтения-записи" используется ключ -w. Вы можете также указать
в командной строке устройство, с которым вы работаете, например /dev/hda1 или
/dev/sda1 и так далее. После вызова debugfs вы увидите ее приглашение.
В этой статье мы рассмотрим только ограниченный набор команд. Я смотрел страницы
man, касающиеся этой команды, но обнаружил, что в моей системе страница, посвященная
debugfs, безнадёжно устарела, и неполностью перечисляет команды debugfs.
Чтобы получить список всех команд, правда без пояснения, что они делают,
можно в командной строке debugfs набрать ?, lr или
list_requests.
Первой командой, которую мы испробуем, будет params, которая
покажет нам, в каком режиме мы находимся (read-only или read-write), а также
текущую файловую систему. Если вы запустите эту команду для несуществующей
файловой системы, обычно она вызовет дамп ядра и завершится.
Две других команды, open и close могут быть интересны,
если одновременно вы работаете с несколькими файловыми системами. Close
не имеет аргументов и, как вы можете догадаться, закрывает файловую систему,
которая была открыта. Open требует в качестве аргумента имени устройства.
Если вам необходимо посмотреть статистику диска из суперблока, команда
stats покажет информацию по группе.
Давайте теперь взглянем на те функции debugfs, с помощью которых можно
работать над фиксацией дефектов нашего жесткого диска. По напечатанному
списку дефектных блоков, нам необходимо просмотреть, какие из блоков
находятся в использовании и какие файлы используют их. Для этого лучше
всего подходит команда testb, примененная к каждому подозрительному
номеру блока, поданному ей аргументом. Если при тестировании окажется,
что блок не используется, мы будем уверены, что в этом слчае потерь данных
нет.
Если блок маркирован как используемый, нам необходимо найти, какой файл
использует этот блок. Мы можем найти inode следующей командой:
icheck
которая в результате своего выполненя вернёт inode, указывающий на блок.
Далее, мы применим
ncheck
чтобы получить имя файла, соответствующего inode. В конце концов мы сможем
предпринять к этому файлу какие-нибудь действия. В заключение, мы можем попробовать
переписать файл, но если блок действительно битый, лучшей идеей будет восстановение
испорченного файла с диска резервной копии. Чтобы освободить блок, можно использовать
одну из нескольких команд; Я рекомендую первую из них:
cleari
Эта команда выводит из использования inode и соответствующие блоки. Обратите
внимание, чтобы сделать это, вы должны быть в режиме read-write. Данные команды
невозможно отменить.
После того, как дефектный блок был освобождён, вы можете использовать:
setb
для постоянного занятия блока, удаления inode, указывающего на него
из пула свободных inode.
На этом всё. Как только соответствующие изменения сделаны для всего
перечня дефектных блоков, можно выйти из debugfs и перезагрузиться. Вы можете
в дальнейшем работать без каких либо проблем, если вы не пропустили какой-либо
блок (или количество дефектных блоков не увеличилось по не зависящим от вас
причинам).
Правильное обслуживание диска требует периодической его проверки.
Вашим лучшим инструментом будет fsck, и вы должны будете запускать эту
программу как минимум раз в месяц. Проверки диска по умолчанию предусмотрены
через 20 перезапусков системы, но если ваша система не выключается по нескольку недель,
возможно, вам время от времени понадобится принудительный запуск утилит проверки.
Наилучшей идеей будет выполнение процедуры системного резервирования и
проверки каталогов lost+founds время от времени. Утилита dumpe2fs
предоставит важную информацию относительно параметров работы жесткого
диска, находящихся в суперблоке, а с помощью badblocks выполнить проверку
поверхности. Окончательная хирургия для удаления дефектных областей с диска
может быть применена путём использования debugfs.
Дэвид Бандел (David Bandel) является консультантом
по компьютерным сетям, специализируется на Linux, кроме того он плотно
работает с Windows и многими серверами на "настоящем" Unix, такими как
DEC серии 5000 и Sun. В свободное от работы время он экспериментирует
над собственной системой или наслаждается видом Сиэтла с высоты 2500 футов
с аэроплана. Автору интересны ваши комментарии, критические заметки,
шутки и он будет счастлив затуманить ваши мозги еще чем-нибудь. Можете
написать ему по e-mail dbandel@ix.netcom.com или послать письмо через
Linux Journal.
|