» Как узнать какой файл расположен в месте пендингов или бэдов

Вопрос такой: каким образом можно узнать,что в 48 кб бэд блоков находятся такие то файлы например? Или есть несколько нестабильных секторов, нужно выяснить что за данные там расположены и переписать их.

FunnyLorax
Самый простой способ - это копирование информации с проблемного раздела на нормальный. Как токо файл будет не читаемым - то операция копирования приостановится и выдаст резюму(имя файла). Если битых файлов немного, то можно применить этот метод(при повторном поиске первый найденный файл надо удалить будет - что проблематично).
Можно попробовать применить например программу типа CDCheck:
http://www.softportal.com/software-351-cdcheck.html

Цитата:

CDCheck - утилита для обнаружения, предотвращения и восстановления поврежденных файлов на CD-ROM

Но ее можно использовать и для проверки файлов на жестком диске...проверено...

Если говорить о DMDE (про другие проги не скажу, бо в прошлый раз нашелся умник, сказавший что это суперсложно), то в ней можно посмотреть карту кластеров. И используя небольшие расчёты выяснить какой файл в каком кластере находится (а может уже и в $BadClus).
Посмотри http://forum.ixbt.com/topic.cgi?id=11:45814-8#234 и ответы автору сообщения - как раз на днях обсуждали.
rodrigo_f
Вообще если уж и копировать для проверки, то зачем на другой раздел а не в null?

9285

Цитата:

то зачем на другой раздел

так это ж самый:
Цитата:

Самый простой способ

предложено было...
а по поводу:

Цитата:

а не в null?

я слышал звон, да не знаю...короче...не знаком близко с такими вещами...

9285

Цитата:

то зачем на другой раздел а не в null?

Чтоб резервную копию иметь, если хард решит окончательно сдохнуть.

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

rodrigo_f

Цитата:

null?

В никуда, в аннигилятор. В старом добром ДОСе так и писалося >NULL.

Тогда объясните,что происходит с моим хардом: бэдов на нем нет,есть пару десятков pending sectors. Проверка chkdsk /r показывает,что достаточно много файлов повреждены (windows replace bad clusters of file ...). После проверки опять смотрю SMART: бэдов 0, пендинги так и остались как раньше.
Если сейчас будет производится чтение данных,они прочитаются правильно? Или битые?


Добавлено:
Можно сформулировать вопрос по другому: как вытащить информацию из pending sectors, именно ту, которая на волосок от гибели,а не тупо копировать Акронисом весь терабайтный винт. И затем почистить эти пендинги, на случай если они программные и образовались в результате сбоя работы NTFS

FunnyLorax
Насколько я понимаю, у винды свои понятия плохих секторов, и уж точно не относятся к релокейтам.
И скорей всего в бэды записываются те самые пендинги. Можешь проанализировать список сбойных секторов (их адреса) и адреса пендинговых секторов.
Показатели SMART не обязательно изменяются моментально, тем более если так и не выяснено какой сектор на самом деле.

tomset
Резервная копия может и есть. Да и не в ней дело а в том как реализуется поставленная задача. Во первых это дольше, во вторых - если потом данные с другого раздела будут удаляться, то оставят мусор.

А как вообще работает pending? Не могу найти в интернете ничего внятного
Ну к примеру сейчас там записан файл, CRC повреждена или сектор не стабилен - его записали в pending sectors. Если я удалю файл, это место очистится - пендинг сохранится или нет? Если в секторе ничего не хранится,то логично что и контрольной суммы у него нет или она равна 0.
Или к примеру скопировать файл с проблемного диска на исправный, и затем обратно его вернуть.


Добавлено:
Да и ещё: прогон MHDD\Victoria с включенным ремапом по pending sectors превратит их в настоящие бэд-блоки, и уже безвозвратно? Содержимое G-List ведь без технологического софта изменить невозможно.

Цитата:

А как вообще работает pending?

Да вроде - почти никак Пендинги - это нестабильные сектора. Такое понятие есть только с точки зрения диска (в ФС - нету, поправят, если что). А вот диск пока не заремапит этот сектор и если он читается (с задержкой) - то инфа из него тоже будет читаться. Как только он определится как бэд - сектор замещается новым из резервной области...
А вот как относится к таким секторам ФС и помещает ли она пендинги в BadClus - это 9285 думаю пояснит...

Цитата:

CRC повреждена или сектор не стабилен

Это вообще-то ДВЕ РАЗНЫХ вещи. CRC может быть не повреждена, но сектор будет нестабильным (вернее медленночитаемым, имеется в виду). А вот если CRC повреждена - то там уже и бэд может быть.
Тут ведь какое дело: говорят, что современные диски почти всех производителей в 5-м атрибуте НЕ ОТРАЖАЮТ реальное количество секторов в G-list. И вообще показывают атрибут нулевым, пока в G не появится ну там 50-100 секторов отремапленных Так что SMART вам может врать относительно того, есть ли УЖЕ бэды или нет, имейте в виду...

Медленные сектора к пендингам ни как не относятся.
Хоть 5 секунд задержку дают.
В канидаты попадают только сбойные сектора. которые не удалось вычитать обычными командами чтения.
Затем хард смарт-тестами будет пытаться его вычитать. Если вычитается, то запишется на место и проверится чтением. Если не прочтется, то переназначится.
Если не вычитается, так и останется кандидатом до новой записи в него.
При новой записи все сектора отмеченные в логах, проверяются чтением.
Не отмеченные в логах, не проверяются после записи.

Victoria 4.46 находит сектора UNC ,отмечены крестиком. Проход с ремапом ничего не дает, и erase тоже ничего не дает. Данные с винта читаются нормально. Так вот непонятно, как же он их читает если там куча неисправных секторов - "спасенная" информация повреждена?
Копировал в Total Commander на другой винт, скопировал около 300 гигабайт - количество пендингов вообще не изменилось даже.

FunnyLorax
Значит сбойные сектора не попадают на файлы.

DMDE оказывается умеет вычислять имя файла по номеру LBA. Для этого он сканирует MFT диска. Victoria показывает блок LBA 66300384 UNC , ввожу этот адрес в DMDE, нажимаю "Данные файла", показывает название nvcuvenc.dll.
Нахожу этот файл,копирую на диск - он читается. Почему же тогда сектор UNC?

ПАтАмуШто:

Цитата:

блок LBA

А не сектор.
Чтобы выяснить сбойный сектор, надо прочитать сбойный блок (256 секторов) по одному сектору.

Ну то есть в Victoria надо масштаб увеличить? Там 32 сектора самый крупный.
Сейчас у нас дефект с точностью до LBA, а надо узнать с точностью до сектора,коих в ЛБА аж 256 штук? Правильно я понимаю?

Цитата:

Ну то есть в Victoria надо масштаб увеличить? Там 32 сектора самый крупный.

Или перейти в PIO-режим.

Цитата:

надо узнать с точностью до сектора,коих в ЛБА аж 256 штук? Правильно я понимаю?

Нет. Блок ЛБА = 256 секторов.

FunnyLorax

Цитата:

Victoria показывает блок LBA 66300384 UNC

Задаете его как старт ЛВА.

Цитата:

Ну то есть в Victoria надо масштаб увеличить? Там 32 сектора самый крупный.

В окне выбора размера блока (блок сайз) нажимаем ручками на клаве 1 и делит.
Потом мышкой кномпочку старт...

Нашел нечитаемый сектор, он в DMDE с первого раза выдает ошибку CRC. Повтор - читается.
Файл,записанный в нем,нормально читается с первого раза. Удалил этот файл.
Теперь можно редактировать этот сектор как угодно? По идее нужно туда записать какие-нибудь данные и он возможно регенерируется. На время какое-то

Цитата:

и он возможно регенерируется

А может и заремапится, как повезёт

Добавлено:
PS Возможно это был софт-бэд

Цитата:

Возможно это был софт-бэд

Да не похоже.Многократно там стирали его, слабые секторы. Пыль или грязь на магнитной поверхности возможно. Хотя по кабелю тоже ошибок море, в корпусе тесно - интерфейсные кабели гнутся на излом,так что у хардов коннекторы аж прогибаются. Вот там и Write Error Rate уже упал до 1-цы

Цитата:

Write Error Rate

??? это исключительно внутренний параметр винта, не связанный, насколько мне известно, с кабелем. Мы тут всё обсуждали общую теорию, а может вы озвучте модель диска и SMART покажите. А то может, то, чем вы занимаетесь, спасёт вас ненадолго. И диску требуется более серьёзное вмешательство, чтобы продлить его существование (и его реально сделать, если это например Сигейт Барракуда...)

Цитата:

Write Error Rate уже упал до 1-цы

Цитата:

вы озвучте модель диска и SMART покажите.

Хреново для любой модели.

Да вроде как Raw Error Rate и Write Error Rate и прочие статистические параметры не особо существенны. На Сигейтах к примеру Raw Error Rate всегда огромен т.к. считает вообще все ошибки при чтении, которые другие харды скрывают от пользователя.

AntiBingo
Сигейты в Raw Error Rate считают все операции и хорошие и плохие, а результат частоты ошибок подсчитывается в Value.

Цитата:

Raw Error Rate

и сигейты - это да, спору нет. Про чтение... А вот ОШИБКИ ЗАПИСИ - это как выше сказал AntiMember

Цитата:

Хреново для любой модели

Поэтому надо разбираться. Возможно у вашего винта "контактная болезнь", особенно если Сигейт. Не мешало бы проверить для начала:
Ложите винт на стол платой электроники вверх. Откручиваете плату. На обратной стороне ищите два ряда контактных площадок, идущих в гермоблок (на гермоблоке в этом месте колодка с контактами), а также 3-4 контактных площадки, идущих к контактам двигателя. Чистите все эти контакты обычной стёркой. В статье есть фото http://www.hddprotector.com/controller.htm Чистить точки А и В.

Ну и SMART хоцца посмотреть, если не секрет...

Ну по крайней мере, гарантийные отделы не примут "дефектный" диск из-за write error rate.
Критическим аттрибутом является только количество reallocated sectors, остальное - так, для сведения. Я думаю если винт работает нормально,то вообще нет смысла обращать внимания на эту статистику появления ошибок. ХЗ как производитель реализовал алгоритм счета

AntiBingo

Цитата:

Критическим аттрибутом является только количество reallocated sectors, остальное - так, для сведения.

Есть еще утили от производителей, у которых есть тесты, которые при критических ошибках
выдают фе(fail) и код ошибки для вендора. Пусть гарантийщики тогда помашут пятым атрибутом.

Удалось убрать все пендинги с помощью программы Hard Disk Sentinel в режиме Тест поверхности: ЧТЕНИЕ+ЗАПИСЬ+ЧТЕНИЕ (регенерация диска). При этом все данные сохраняются. Не знаю,насколько это поможет. Такое ощущение,что у диска бывают глюки именно при записи. Если сектор записался нормально,то с чтением проблем нет