Сэр Серж aka Sir Serge (Сергей Лебедев) - official site
Статьи и заметкиРасчетыСтихиПрозаО сайте

Работа в Linux с битыми носителями

Есть вещи, которые сами собой разумеются, и есть вещи, которые подразумевают себя неявно.

В случае обнаружения работы Linux на носителях, которые по тем или иным причинам имеют дефектные области, могу дать только одну нормальную рекомендацию - немедленно замените этот носитель. Несмотря на восторженные вопли фанатов о том, что Linux "может работать на чём угодно", имейте в виду: это "что угодно" должно представлять собой абсолютно исправную аппаратуру. Особняком стоит флоппи дисковод 3.5", дискеты почти всех производителей для которого последнее время характеризуются крайне низкой надежностью и качеством, усугубляемыми еще и тем, что фактически этот привод всегда работает на пределе технологии: судите сами, взят магнитный материал, практически не отличающийся по своей структуре от того же, из которого делались ставшие уже историей (и, кстати, весьма надёжные!) дискеты 5.25", и путем уменьшения размера пластинки, ширины дорожки и резкого увеличения плотности записи до предела, достигнута ёмкость хранения данных, при которой уже начинает сказываться фактор стабильности носителя. Что же, спросите вы, делать, если вы вынуждены еще пользоваться дискетами? Непатриотично призываю вас в этом случае размечать их под FAT и пользоваться для коррекции дефектных областей утилитами для Windows - сэкономите массу полезного времени.

Гораздо хуже, если дефектные блоки обнаруживаются на вашем жестком диске. Кроме всего прочего, на жестком диске есть еще область, в принципе не подвергающаяся какому либо контролю и закрыванию дефектов - это раздел свопа. Никаких утилит для его исправления и изымания из него дефектных областей в Linux не предусмотрено вообще, да и самой возможности в этой файловой системе как-то помечать дефектные блоки - тоже. Поэтому, корректируя битые места вашей основной файловой системы, всегда имейте в виду, что своп вам не поправить никак, и если дефектная область придётся на него, кто может гарантировать стабильность вашего пингвина? Так, что нужно делать, еще раз? Правильно - немедленно заменить жесткий диск. Ничто не оправдает вашу жадность.

Рекомендации к тому, как закрыть дефектные области вручную, приведены после моего текста. Эта статья была обнаружена мною в результате вполне безуспешных поисков по интернету и оказалась единственной, имеющей отношение к проблеме. Что еще раз подтверждает: пользователи и разработчики Linux - люди настолько обеспеченные, чтобы никогда не сталкиваться с необходимостью работы на носителях, содержащих физические дефекты. Копирайт на перевод - мой. В некоторых местах я намеренно не стремился сохранить полную аутентичность исходному тексту, потому что... ну не говорят так по-русски, sorry.

До того как воспользоваться рекомендациями статьи, настоятельно советую проверить диск специальной утилитой от производителя HDD, предназначенной для этих целей. И воспользоваться рекомендацией диагностики. Неплохая утилита для дисков IBM/Hitachi носит название DFT, формально можно применить ее и для диагностики винчестеров других производителей. Гораздо хуже - ПО от Samsung, не предоставляющее практически никакого инструментария, кроме диагностики самой по себе.

Существует еще замечательная программка под названием mhdd (естественно, работает исключительно с загрузочного диска DOS, и только для дисков IDE), с помощью которой можно капитально надругаться над вашим винчестером, закрыть все дефекты поверхности, вплоть до отключения отдельных головок, поверхностей, подмены геометрии - но ею при некорректных действиях точно так же можно легко, полностью и необратимо вывести винчестер из строя окончательно. Так что думайте, прежде чем делать и хорошо осознавайте предпринимаемые вами действия. В любом случае, после такой коррекции вы потеряете все содержимое ваших файловых систем: ремаппинг производится на физическом уровне диска, а не на логическом и не заботится о сохранности информации. Это, так сказать, радикальные способы решения проблемы.

Для тех, кто не знаком с технологией автоматического ремаппинга дефектных областей внутренним контроллером современных HDD, рождающей многочисленые легенды о самопроизвольном пропадании дефектных блоков и так называемых "программных" дефектных блоках, скажу следующее: во-первых, "программных" дефектных блоков не существует в природе. Якобы их "исчезновение" в результате переформатирования связано с тем, что ремаппинг дефектных блоков на служебную дорожку происходит исключительно во время операции записи, так как это - единственная ситуация, в которой контроллер может пересохранить данные без их искажения. То есть, если в результате операции чтения обнаруживается несовпадение контрольной суммы блока данных, данный сектор не может быть откорректирован контроллером до тех пор, пока контроллеру не будет дана команда на его запись. Во-вторых, в отличие от Windows, у которой по малейшем поводу запускается утилита сканирования поверхности диска, производящая чтение и перезапись секторов, тем самым инициирующая принудительно ремаппинг дефектных участков (кстати, именно по этой причине Windows может "падать" по непонятным причинам после работы такой утилиты), все чекеры поверхности диска Linux по умолчанию проверяют поверхность диска исключительно операцией чтения, что инициировать ремапинг никак не может, и дефекты склонны только накапливаться, но не исчезать "самопроизвольно", что вкупе с "ленивой" политикой использования дискового пространства значительно оттягивает появление диагностических сообщений до обвального ссыпания HDD, в отличие от... сами понимаете в отличие от чего.

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

Если ничего не помогло, читайте дальше. Однако, во-первых, обратите внимание на то, что статья написана в 1997 году, то есть очень давно. Во-вторых, рекомендации, возможно, вам не помогут, если дефекты пришлись на раздел, отформатированный не в ext2/ext3. К слову сказать, после трех неудачных попыток чтения дефектного сектора, относящегося к корневому разделу системы, ReiserFS, например, просто повесит намертво ядро и заблокирует все активные процессы с выдачей соответствующего предупреждения на экран - и сомнительно, чтобы вы что-то смогли с этим сделать. Тем более, как раз для этой файловой системы рекомендации статьи не действуют, а утилит автоматического самовосстановления reiserfs для случаев обнаружения сбойных по вине оборудования участков, конечно же, не предусмотрено.

* * *

Перевод статьи,  написанной "Фишки обслуживания дисков -- что вы об этом должны знать и делать". (расположено в рамке).


Давайте рассмотрим, что делать в следующей гипотетической ситуации. Вы работаете в вашей линуксовой консоли, делаете вызов приложения или обращение к файлу с данными, при этом 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 вы можете модифицировать диск методом прямой записи. Поскольку эта утилита обладает такой мощью, вы должны обычно запускать её в режиме "только для чтения" до тех пор, как вы действительно будете готовы применить изменения и записать их на диск. Чтобы вызвать 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.


Всего комментариев: 1

Станислав OC: Windows XP   2008-09-02 23:11:19


Здрвствуйте!!!

Помогите с провлемой

Не загружается RedHat
Загрузка останавливается на сообщении
ext 3- fs error (device ide 0(3, 2 )):
ext 3 _ get _ inode _ loc : unable to read inode block- inode =1599379, block = 3211266
sh - 2.05b#_

Пробовал запустить sfck, но система сообщает что такая команда не найдена (command not found)

Посоветуйте что в этом случае можно сделать чтобы востановить систему без инсталляции.

Заранее благодарен за скорый ответ

С уважением,
Станислав



Вы можете добавить свои комментарии.

Поскольку у нас тут абсолютная демократия, то комментарий появится на сайте только после того, как он будет одобрен администрацией. Оперативности, однако, не обещаем.

Прошу соблюдать относительную корректность в высказываниях. Заявления типа "Пошел на...", посты, написанные в олбанской лексике и психоанализ личности автора и участников обсуждения в свет не выйдут. Также будут блокированы сообщения, не имеющие никакого отношения к заявленной тематике. Если вы не согласны с приведенным текстом - выскажите своё мнение, но обосновывайте его. Помните, что свою позицию доказываете Вы не мне, а другим читателям. Всячески приветствуются возможные технические поправки и исправления неточностей. Для возможности внесения комментариев в браузере должна быть включена поддержка JavaScript. Реклама и ссылки на сайты, не относящиеся к делу, являются прямым основанием блокировки. Поля "E-mail" и "WWW" обязательными для заполнения не являются, поле E-Mail не публикуется. Если хотите просто что-то написать автору статьи, без публикации на сайте - воспользуйтесь специальной формой под пунктом меню "О сайте". Администрация оставляет за собой право публиковать или не публиковать адреса, введенные в поле www, а также при необходимости редактировать текст вашего сообщения. Ответы на ваши сообщения по введенному вами E-mail автоматически сайтом не высылаются. Да, теги PHPBB и HTML не действуют, так что не старайтесь их вводить.

Copyright © 2003-2018 by Sir Serge