При обнаружении bad-секторов программами типа Victoria будет весьма полезно узнать, какие именно файлы записаны в поврежденных секторах. Сопоставление принадлежности проблемного сектора конкретному объекту файловой системы также может пригодится при поиске содержащего строку файла, обнаруженную в секторе в процессе анализа дампа диска. Задача кажется сложной, на самом деле всё очень даже просто, если под рукой у вас имеется утилита NFI, входящая в состав пакета Sysinternals Suite.
Предположим, что при сканировании диска той же Victoria вы обнаружили bad-блок. Чтобы получить его номер, наведите на него мышку.
В нашем примере это 14822144. Теперь это значение нужно скормить утилите NFI, правда, здесь есть одна маленькая проблема. Помимо номера блока в качестве обязательного аргумента нужно указать еще и букву логического раздела, а Victoria прямо не сообщает, в каком томе был обнаружен проблемный сектор. Зато она показывает начальные и конечные номера секторов, и это будет нашей подсказкой.
Переключитесь в Victoria в раздел «Редактор» и нажмите кнопку «Таблица разделов». Слева тут же появится таблица, в которой будут перечислены все логические разделы на сканируемом диске. Букву тома определяем по его размеру или имени, если Victoria его покажет.
Смотрим и видим следующую картину. Первый загрузочный том у нас начинается с сектора 2048 и заканчивается сектором 1126399. Следующий том, определенный как системный, начинается с сектора 1126400 и заканчивается сектором 63895551. Битый сектор же у нас имеет номер 14822144.
Выполнив простейший арифметический подсчет, определяем, что блок находится на системном томе C.
Запустив командную строку от имени администратора переходим в папку с утилитой NFI.EXE и выполняем команду nfi.exe C 14822144.
В результате получаем лежащий в проблемном секторе файл — pagefile.sys.
Как видите, ничего запредельно сложного, сомнения насчет расположения файла в данном секторе могут возникнуть, если только размер обнаруженного файла сопоставим с размером сектора. А всё потому, что Victoria работает с секторами всего диска, а утилита NFI.EXE — с секторами томов. Поэтому знать границы разделов не помешает.
Что касается сопоставления известного файла сектору, то тут еще всё проще, номер блока в два счета определит бесплатный шестнадцатеричный редактор WinHex.
Запустив приложение, выберите в меню «Tools» опцию «Open Disk».
И укажите в открывшемся окне том, в котором лежит файл.
Вот и всё, осталось только найти во встроенном файловом менеджере нужный файл, выделить его и посмотреть в левый нижний угол рабочего окна редактора.
Там, в строке состояния будет указан порядковый номер сектора, содержащего интересующий вас объект.
Утилита NFI отдельно: yadi.sk/d/iy7DlmD_Gqmwqg
(2 оценок, среднее: 4,50 из 5)
Загрузка...
WinHex не бесплатный. А в демо версии есть ограничения. Но в нём тоже можно найти имя файла по номеру сектора.
В статье грубая ошибка! Автор путает понятия сектора и блока сканирования. Цитата: "В нашем примере это 14822144. Теперь это значение нужно скормить утилите NFI" - ошибочна. Судя по первому скрину, 14822144 - это не бэд-блок и не бэд-сектор. Дефектные блоки, найденные Викторией, помечаются синим цветом, а не красным как на скрине. 14822144 - это первый сектор медленного блока, время доступа к которому лежит в диапазоне от 600 мс до 10 сек(таймаймаут на скрине 10000мс). Это рабочий блок секторов, просто по каким-то причинам доступ к нему на период обращения был чем-то замедлен. Чем - это уже другой вопрос, но это и близко не бэд-блок или бэд-сектор. По скрину видно, что его фотошопили, ибо сей красный блок должен был отрисоваться в виде цифры 1 на цветной панели блоков, но там цифра 0. Кроме того, все найденные дефектные блоки писались бы лог, даже медленные красные если была проставлена соответствующая галка в настройках.
Ну допустим, что наш скрин был бы нормальным и мы бы действительно нашли один синий блок начинающийся с 14822144, но далеко не факт, что это именно бэд-сектор. Его нельзя кормить утилите NFI как сделал автор. 14822144 - это всего лишь номер первого сектора синего блока размером в 256 секторов(судя по скрину). Это просто первый сектор блока секторов. В этом блоке, помимо него - еще 255 секторов. На скрине, на карте блоков у найденного блока явно же показан его диапазон LBA 14822144...14822399. Бэд-сектор, один или несколько, находится где-то внутри этого диапазона, да он может быть первым 14822144, но запросто может быть и последним 14822399. Мы не знаем точно, какой из секторов блока привёл к тому, что Виктория не смогла прочесть сей блок секторов за 10 сек. Может там все 256 сектора плохие, а может какой-то один находящийся в середине блока. А автор статьи взял и скормил первый сектор 14822144 программе NFI, который запросто мог быть хорошим сектором. В итоге, автор думает что файл pagefile.sys - битый, но сие далеко не факт. Чтобы найти бэд-сектор, надо пересканить диапазон LBA 14822144...14822399 в посекторном режиме. По дефолту, Виктория сканит винт "блоками секторов", так получается быстрее, чем сканить каждый сектор по отдельности. И в этом то и проблема, что любой бэд-сектор из блока секторов может привести к тому, что весь блок будет признан дефектным. Размер блока по дефолту выбирается атоматом в зависимости от типа и размера винта. Судя по скрину, Виктория сканила блоком в 256 секторов. И для скана нашего диапазона в посекторном режиме, нужно вручную на главном окне через одноимённый комбобокс сменить число 256 на 1, т.е. сменить размер блока с 256 секторов на 1 сектор. Далее, в текстбокс "Start LAB" нужно ввести 14822144, а в текстбокс "End LBA" ввести 14822399. После нажать на кнопку Scan. И тогда Виктория просканит нам каждый сектор индивидуально и мы узнаем какие именно из 256 секторов - бэд-сектора, а какие здоровые. И именно, найденные бэд-сектора и надо будет скормить NFI. В общем, автору надо переписывать статью и исправлять данные ошибки.
К предыдущему моему комменту дополню. Помимо ошибок изложенных в моем комменте выше, я обнаружил дополнительные ошибки в статье. Ошибки касаются использовании утилиты NFI, с которой я ранее не работал. Автор неверно скормил ей свой так называемый "бэд-сектор". Сектора бывают 2 видов: физические и логические. Физические сектора - считаются от начала hdd, т.е. с 0. Логические сектора(сектора тома/раздела/логического_диска) - считаются от начала конкретного тома. Физические сектора - они глобальны и охватываются весь hdd, охватывают все тома/разделы/логические_диски. А логические сектора - они локальны, т.е. суб-сектора принадлежащие конкретному тому/разделу/логическому_диску и у них своя независимая суб-нумерация. Нумерация физических и логических секторов - различается. Согласно скрину №1 с Викторией на HDD содержится: LBA = 104857600 физических секторов, нумерация 0...104857599. Согласно скрину №2 у нас на HDD имеются 3 тома: 1(576МБ): LBA c 2048 по 1126399, 2(32ГБ): LBA c 1126400 по 63895551, 3(21ГБ): LBA с 63895552 по 104853503. У нас 3 группы независимых локальных логических секторов. Автор верно подметил, что сектор 14822144 входит в диапазон тома №2 - диск C, но автор неверно скормил его утилите NFI. Он скормил сей сектор как логический, а он у нас физический! Дело в том, что Виктория выдаёт номера физических секторов, которые считаются от начала hdd. Сектор 14822144 - это номер физического сектора. Утилита NFI - умеет кушать как физические так и логические сектора, но подавать их ей их нужно по-разному. Если мы ей подаём логический сектор, то нужно указать конкретный том(буква логического диска) и № логического сектора. Именно так и сделал автор, он указал имя диска C и № 14822144, но это не номер логического сектора, это номер физического сектора. На скрине №3 ведь прямо указано "Logical sector". Посему утилита NFI выдала ему неверный результат, она ему выдала имя файла, который лежит на логическом секторе №14822144, а нам нужен файл, который лежит на физическом секторе №14822144. Что нужно было сделать автору? Сделать перевод физического сектора в логический. Формула проста: №_лог_бэд-сектора = LBA_физ_бэд-сектора - StartLBA_Тома. В нашем случае №_лог_бэд-сектора = 14822144 - 1126400 = 13695744. Именно № 13695744 нужно было подавать в NFI вкупе с диском C. В томе №2 начиная с физического сектора LBA 1126400(StartLBA) начинается свой суб-отсчет локальных логических секторов: физический сектор 1126400 - соответствует первому(№0) логическому сектору тома №2, физический сектор 1126401 соответствует второму логическому сектору тома №2, физический сектор 1126402 соответствует третьему логическому сектору тома №2 и т.д. то есть, у нас у всех логических секторов тома №2 идет смещение нумерации он начала HDD на число LBA 1126400. Но можно не парится с расчетами, ведь NFI умеет "кушать" и физические сектора, но подавать их нужно иначе. Вместо связки "буква тома + № логического сектора", нужно подать связку "имя физического hdd + № физического сектора". Я об этом способе узнал из этого коммента http://forum.oszone.net/post-2613664.html#post2613664 , но тот коммент большой и со скрином и сюда его скопировать проблематично. В общем, автору статьи нужно её полностью переписать с исправлением всех ошибок. Успехов!