Все про жесткие диски

[Tau_0]

SMART показывает нормально, ремап не проходит. »
Никак затирание/переназначение не произойдёт, поскольку у st500dm002 500gb сбойный блок с началом в LBA = 75517440 UNCR содержит большие секторы…
См. Bytes per sector 4096 (http://www.seagate.com/staticfiles/support/docs/manual/desktop/Barracuda%207200.12/100672652b.pdf)

Покажите хоть рапорт SMART для этого харда.
Обычно сбойный сектор легко зачищается записью восьми обычных секторов по 512 байтов. По адресу LBA сбойного 4096 сектора. Если данные не нужны, то можно и 256 малых секторов (с избытком..) записать по LBA = 75517440 записать.

После этого нестабильный сектор уйдёт…

[Michel-P]

-------------------------------------------------------------------------
ID Name Value Worst Tresh Raw Health
-------------------------------------------------------------------------
1 Raw read error rate 118 91 6 173591914 •••••
3 Spin-up time 100 99 0 0 •••••
4 Number of spin-up times 97 97 20 3522 ••••
5 Reallocated sector count 100 100 36 0 •••••
7 Seek error rate 84 60 30 4544078837 ••••
9 Power-on time 92 92 0 7603 ••••
10 Spin-up retries 100 100 97 0 •••••
12 Start/stop count 97 97 20 3487 ••••
183 unknown attribut 100 100 0 0 •••••
184 End-to-End error 100 100 99 0 •••••
187 Reported UNC error 1 1 0 4706 •
188 Command timeout 100 96 0 89 •••••
189 High Fly writes 100 100 0 0 •••••
190 Airflow temperature 73 51 45 27°C/80°F ••••
194 HDA Temperature 27 49 0 27°C/80°F ••••
194 Minimum temperature 90 49 0 5°C/41°F -
195 Hardware ECC recovered 57 34 0 173591914 ••
197 Current pending sectors 100 100 0 7 •••••
198 Offline scan UNC sectors 100 100 0 7 •••••
199 Ultra DMA CRC errors 200 200 0 0 •••••
240 Head flying hours 100 253 0 177249005346217 •••••
241 unknown attribut 100 253 0 1609597733 •••••
242 unknown attribut 100 253 0 3098456456 •••••

[Tau_0]

Michel-P, более всего нас интересуют следующие атрибуты SMART ---
187 Reported UNC error 1 1 0 4706 •
197 Current pending sectors 100 100 0 7 •••••
198 Offline scan UNC sectors 100 100 0 7 •••••

Атрибут: 187 (BB) Reported Uncorrected Sector Count (UNC Error)Тип накапливающий
Описание содержит количество секторов, которые были признаны кандидатами на переназначение (см. атрибут 197) за всю историю жизни диска. Причём если сектор становится кандидатом повторно, значение атрибута тоже увеличивается

Ненулевое значение атрибута явно указывает на ненормальное состояние диска (в сочетании с ненулевым значением атрибута 197) или на то, что оно было таковым ранее (в сочетании с нулевым значением 197).
См. Оцениваем состояние жёстких дисков при помощи S.M.A.R.T.
(http://www.ixbt.com/storage/hdd-smart-testing.shtml)
Было предпринято 4706 попыток переназначения этих пендингов, но они не принесли успеха.

Я считаю, что эти 7 нестабильных сектораов есть банальные soft-bads, но из-за нестыковки записи по ECC хард сам с ними справится не может, и Виктория тут нам не помошник… Но с помощью Victoria мы можем очень точно поймать адреса этих бэдов, чтобы потом затереть их записью диапазона секторов. Позже я более подробно распишу в чём там дело…

А пока запустите тест линейного чтения (Read+Ignore) в Victoria 4.46b/4.47b. Текстовый рапорт SCAN (в нижнем зелёном окне) приложите к ответу.

ЗЫ Можно и в режиме (Read+Remap) SCAN прогнать, но только ничего не будет переназначено/затёрто. Но рапорт SCAN покажет нужные LBA адреса сбойных секторов. Этот вид рапорта по-своему очень любопытен...

[eco]

187 Reported UNC error 1 1 0 4706 • »
А диск в ОС определяется?

[Michel-P]

Victoria 4.47 Freeware (2013-02-20) log file. 21.02.2015
0:57:32 : Starting Victoria 4.47 Freeware (2013-02-20) , 2xCPU, 3014,22 MHz, Windows XP found.
0:57:32 : API access enabled, device #1
0:57:32 : Get passport... OK
0:57:32 : 48bit access enabled
0:57:32 : Model: ST500DM002-1BD142; Capacity: 976773168 LBAs; SN: Z2AP1Z1F; FW: KC45
0:59:34 : Get S.M.A.R.T. command... OK
0:59:34 : SMART status = GOOD
0:59:53 : Get passport... OK
0:59:53 : Recallibration... OK
0:59:53 : Starting Reading, LBA=0..976773167, sequential access, timeout 10000ms
1:04:50 : Block 75517440 Error: UNCR
2:13:59 : ***** Scan results: Warnings - 0, errors - 1 *****
2:18:13 : Get passport... OK
2:18:13 : Recallibration... OK
2:18:14 : Starting Reading, LBA=0..976773167, sequential access w. REMAP, tio 1000ms
2:22:53 : LBA 75517593 try REMAP... complete
2:22:54 : LBA 75517594 try REMAP... complete
2:22:55 : LBA 75517595 try REMAP... complete
2:22:56 : LBA 75517596 try REMAP... complete
2:22:57 : LBA 75517597 try REMAP... complete
2:22:58 : LBA 75517598 try REMAP... complete
2:22:59 : LBA 75517599 try REMAP... complete
3:31:58 : ***** Scan results: Warnings - 0, errors - 7 *****

[Tau_0]

2:22:53 : LBA 75517593 try REMAP... complete
2:22:54 : LBA 75517594 try REMAP... complete
2:22:55 : LBA 75517595 try REMAP... complete
2:22:56 : LBA 75517596 try REMAP... complete
2:22:57 : LBA 75517597 try REMAP... complete
2:22:58 : LBA 75517598 try REMAP... complete
2:22:59 : LBA 75517599 try REMAP... complete »

Виктория написала, что переназначила 7 обычных 512 байтовых секторов, но на самом деле это не так...

Для каждого сектора с данными имеется поле ECC, предназначенное для коррекции ошибок. При записи данных сектора высчитывается значение ECC и помещается в это поле. Этим делом занимается сам хард на аппаратном уровне. При последующем чтении сектора считанные данные проверяются и верифицирутся с помощью ECC. Так называемые коды Хеминга позволяют на лету скорректировать несколько ошибочных битов в секторе.

Но иногда случается, что хард по каким-то причинам не записывает верное значение в поле ECC. Что-то ему помешало это правильно сделать --- случайные сбои от перегрева, питания, тряски, луны Юпитера не так в линию стали… А так ничего более серьёзного и нет… Но самостоятельно хард с этой проблемой (нестыковкой по ECC) не справится. Но если записать в сектор какие-либо данные, то в этот раз данные запишутся правильно и поле ECC будет правильным. --- Сектор вернётся в строй.

На малых секторах это работало на ура... Но время ушло вперёд и появились 4096 секторы. А такие утилиты, как Виктория предназначены для работы с секторами 512 байтов и не знают про существование 4096 байтовых секторов. Если сектор 4096 байтов читается, то хард нормально эмулирует 512 байтовые секторы. Поэтому он запишет 512 байтовый сектор в сектор 4096 байтов. Но если 4096 нестыковка по ECC, то в этот сектор записать 512 байтов нельзя потому, что не выберутся 4096 байтов.
1. Хард в свою память выбирает 4096 байтов
2. В нужное место по смещению 0, 1, 2, …, 7 записывает 512 байтов
3. Обратно записывает 4096 байтов

Итого для запись 512 байтового сектора нужны три операции.
См. Advanced Format (http://www.wdc.com/wdproducts/library/WhitePapers/RUS/2579-771430.pdf)


Но если писать восемь 512 байтовых секторов, то никакая предварительная выборка 4096 байтов не нужна. Хард просто запишет эти 4096 байтов и правильное значение ЕСС.

Записать диапазон секторов можно в дисковом редакторе.
1. Скачайте дисковый редактор DMDE (http://dmde.com/download.html) --- редактор прост и не требует установки. Можно его с флешки запускать
DMDE - DM Disk Editor and Data Recovery Software
GUI for Windows

2. В DMDE Сервис ===> Заполнить секторы
заполняете шаблон
Сервис ===> Заполнить секторы
заполняете шаблон
Начальный сектор = 75517592
Конечный сектор --- само посчитается
Число секторов = 8
И Ok

ЗЫ Будьте внимательны и заполните нулями нужный хард. --- Потёртую информацию ничем нельзя восстановить.

3. После этого вновь в Victoria прогоняете тест ===>

В Victoria просканируйте узкий диапазон. Это мигом отработает.
StartLBA = 75517440
EndLBA = 75517440 + 255 = 75517695

Показываете рапорты SCAN и SMART

[misha2]

По сути дела, речь идёт о Сигейте известной архитектуры F3. Мрут они реально как мухи. "Лечение" ремапами приведёт к заполняемости G-листа и "слёту" трансляции.
Поэтому всё лечение у таких Сигейтов сводится к пересчётам транслятора с переносом дефектов (записей) из G-листа в Р-лист и последующим техноформатом через терминал. Операции техноформатов многочасовые, бывает и по 1-3 суток.
Такая вот многоступенчатая процедура лечения. Да и то, которая продлевает жизнь такому винту на 3-5 месяцев всего.

[Michel-P]

Victoria 4.47 Freeware (2013-02-20) log file. 22.02.2015
3:11:41 : Starting Victoria 4.47 Freeware (2013-02-20) , 2xCPU, 3014,18 MHz, Windows XP found.
3:11:41 : API access enabled, device #1
3:11:41 : Get passport... OK
3:11:41 : 48bit access enabled
3:11:41 : Model: ST500DM002-1BD142; Capacity: 976773168 LBAs; SN: Z2AP1Z1F; FW: KC45
3:11:51 : Get S.M.A.R.T. command... OK
3:11:51 : SMART status = GOOD
3:16:00 : Get passport... OK
3:16:00 : Recallibration... OK
3:16:00 : Starting Reading, LBA=75517440..75517695, sequential access, timeout 10000ms
3:16:00 : ***** Scan results: no warnings, no errors *****
3:16:10 : Get passport... OK
3:16:10 : Recallibration... OK
3:16:10 : Starting Reading, LBA=75517440..75517695, sequential access w. REMAP, tio 1000ms
3:16:10 : ***** Scan results: no warnings, no errors *****

ST500DM002-1BD142 Z2AP1Z1F
-------------------------------------------------------------------------
ID Name Value Worst Tresh Raw Health
-------------------------------------------------------------------------
1 Raw read error rate 119 91 6 207911208 •••••
3 Spin-up time 100 99 0 0 •••••
4 Number of spin-up times 97 97 20 3527 ••••
5 Reallocated sector count 100 100 36 0 •••••
7 Seek error rate 84 60 30 4544259568 ••••
9 Power-on time 92 92 0 7618 ••••
10 Spin-up retries 100 100 97 0 •••••
12 Start/stop count 97 97 20 3492 ••••
183 unknown attribut 100 100 0 0 •••••
184 End-to-End error 100 100 99 0 •••••
187 Reported UNC error 1 1 0 4706 •
188 Command timeout 100 96 0 89 •••••
189 High Fly writes 100 100 0 0 •••••
190 Airflow temperature 68 51 45 32°C/89°F ••••
194 HDA Temperature 32 49 0 32°C/89°F ••••
194 Minimum temperature 90 49 0 5°C/41°F -
195 Hardware ECC recovered 56 34 0 207911208 ••
197 Current pending sectors 100 100 0 0 •••••
198 Offline scan UNC sectors 100 100 0 0 •••••
199 Ultra DMA CRC errors 200 200 0 0 •••••
240 Head flying hours 100 253 0 127208341380536 •••••
241 unknown attribut 100 253 0 1611919908 •••••
242 unknown attribut 100 253 0 946199919 •••••

[Tau_0]

197 Current pending sectors 100 100 0 0 •••••
198 Offline scan UNC sectors 100 100 0 0 ••••• »
Видно, что нестабильный сектор затёрт, а не переназначен... ===>
5 Reallocated sector count 100 100 36 0 ••••• »
--- Это главное. Поэтому уйдёт он из G-list.

Касательно атрибута ID = 187 ===>
187 Reported UNC error 1 1 0 4706 • »
Так он информационный..., и Бох с ним...

[Michel-P]

Так он информационный..., и Бох с ним... »
Спасибо большое! Сколько еще такой винт проживет? В принципе все эти дни система работала нормально без сбоев

[Tau_0]

В принципе все эти дни система работала нормально без сбоев »
Если Вы форматировали раздел, где жил этот soft-bad, то бэд должен был быть выброшен из системы и помещён в метафайл $BadClus. Поэтому система на нём тормозить/терять данные не должна, но хард сам по своему почину переодически будет пытаться исправить ошибку. Так вот теперь, по-любому, он этого делать не будет.

Проверьте наличие сбойных кластеров. Для этого надо напустить на раздел/том чекдиск в режиме только чтения.

Пуск ===> Выполнить ===> CMD (с правами администратора на Windows 7 и выше)
CHKDSK X: без ключей
где X: --- реальная буква диска

Рапорт чекдиска сохраните и покажите...

Сколько еще такой винт проживет? »
Сиё мне неведомо --- ВСЕ мы под Богом ходим... А ошибка была пустяковая, но и такая порой сильно вредить может...

[Michel-P]

Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.

c:\>chkdsk c:
Тип файловой системы: NTFS.

ВНИМАНИЕ! Параметр F не указан.
CHKDSK выполняется в режиме только чтения.

Проверка файлов (этап 1 из 3)...
Проверка файлов завершена.
Проверка индексов (этап 2 из 3)...
Проверка индексов завершена.
Проверка дескрипторов безопасности (этап 3 из 3)...
Проверка дескрипторов безопасности завершена.
CHKDSK проверяет журнал USN..
Завершена проверка журнала USN
Исправление ошибок в рисунке тома.
Windows найдены ошибки файловой системы.
Запустите CHKDSK с параметром /F (fix) для их исправления.

53553462 КБ всего на диске.
6335672 КБ в 18233 файлах.
5052 КБ в 2026 индексах.
0 КБ в поврежденных секторах.
92546 КБ используется системой.
65536 КБ занято под файл журнала.
47120192 КБ свободно на диске.

Размер кластера: 4096 байт.
Всего кластеров на диске: 13388365.
11780048 кластеров на диске.

[Tau_0]

0 КБ в поврежденных секторах. »
На диске C: метафайл $BadClus пуст...
Возможно, что сектор LBA = 75517592 принадлежит другому диску…???...
Из DMDE покажите скрин окна Разделы диска для этого носителя/драйва.
См. первую картинку (http://dmde.com/images.html)

Так мы точно найдём раздел, на котором лежит этот сектор.

[Michel-P]

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

[jack.vorobey.5@fb]

Доброго времени суток!
У меня хранится много важной инфы на HDD. Эти диски могут подолгу (4-6 месяцев) не подключаться к компу и к тому же инфа не перезаписывается, а лежит на дисках "мертвым грузом". Боюсь может размагнититься. Можно ли это предотвратить? Может нужно через какой-то промежуток времени диски перезаписывать?

[ShaddyR]

оюсь может размагнититься »
абсолютно беспочвенно.

[jack.vorobey.5@fb]

ShaddyR, почему беспочвенно? Частично же могут появиться секторы с ослабленным сигналом или размагниченные участки.

[ShaddyR]

Частично же могут появиться секторы с ослабленным сигналом или размагниченные участки. »
с чего бы?

[Tau_0]

с чего бы? »
С того, что есть такое дело, как саразмагничивание поверхности носителя. Магнитные ленты, а также флоппи диски размагничиваюся только так... --- С этим я сам сталкивался на практике. А вот данных о том, как долго (в годах) могут хранить информацию харды, я не встречал...

Ничто не вечно под луной...:(

[ShaddyR]

С того, что есть такое дело, как саразмагничивание поверхности носителя. Магнитные ленты, а также флоппи диски размагничиваюся только так... --- С этим я сам сталкивался на практике. А вот данных о том, как долго (в годах) могут хранить информацию харды, я не встречал... »
проще говоря - сказал бы, лишь бы сказать? :) Человек интересуется возможностью ухудшения читаемости ж.диска, пролежавшего в нерабочем состоянии N лет. У тебя есть сведения о таких случаях? У меня нет. Зато у меня есть пара MFM-овских\SCSI ж.дисков на несколько десятком мегабайт емкости - с вполне читаемой\пишаемой поверхностью, я уж молчу про устройства ёмкостью в гигабайты - замечательно бегают экземпляры 90-х-00-х годов производства, причем многие из них последние лет 10 могли тихо спокойно пылится на полке.
Короче: причем здесь дискеты и теоретические выкладки о похожести механизма?