Програмный ремонт жёстких дисков HDD (Програмный (и не только) ремонт классических жёстких дисков HDD /Seagate /Samsung /IBM /Hitachi /HGST /Western Digital)
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
KALDYH, в online документации Scribd, по Вашей ссылке, есть упоминания весьма полезных
команд, кстати я нашел эту документацию в нормальном pdf здесь:
http://files.hddguru.com/download/Datas ... 0commands/
Методика ручного добавления дефектов в дефект-листы, в процессе изучения, пока проверялсь
на не сильно нужном barracuda-образном U5 и вышеупоминавшейся PATA ALPINE 80GB, возможны
возможны ошибки в описании. На U5 странности есть (не всегда правильно пишется номер
дефектного сектора (со смещением), но я на нем пока не восстановил ATA overlay, может-быть
из-за этого?).
Есть команда F на уровне 2>, выполняющая форматирование заданного трека или сектора
(она похожа на команду F на уровне 9, которая была у non-barracuda накопителей, U series).
Излагаю в своем переводе, с исправлением ошибки. Дополнения/поправки/замечания приветствуются!
Заданный физический трек заранее нужно выбрать, позиционируя на уровне 2, команда s. Для
7200.9 и новее может понадобиться ключ подтверждения 22, проверяйте правильность
позиционирования по команде <.> Текущий сектор после этого может быть разным, но мы явно
указывем нужный сектор в последующих командах.
Формат команды
Fx,Op,,a
где x - номер сектора, если не введено, форматируем трек (просто F без ничего).
Op - операция (ABDEF)
a - если отсутсвует, то ввводим логический сектор, иначе, если <a> введено (проверял
с 1 и 22), то физический.
Команда 2>F без ключей типа операции и номера сектора форматирует заданный трек (на который
мы позиционировались). При этом slip сектора остаются на своих местах. Происходит ли при этом
частичный пересчет транслятора?
Команда 2>F с отсутствующим ключем операции, но с номером сектора (Fx,,,a) форматирует
сектор x и отмечает его как good (заносит в поля данных сектора правильную ECC?). Удаления
из slip-list этого сектора при этом не происходит.
Команды F с ключами операций:
Op A -> Fx,A,,a Форматируем сектор x и добавляем его в Alt list
Op B -> Fx,B,,a Форматируем сектор x и отмечаем его как плохой (makebad?)
Op D -> Fx,D,,a Форматируем сектор x и добавляем его в slip list (только для UA)
Op E -> Fx,E,,a Форматируем сектор x и добавляем его в slip list (только для SA)
Op F -> Fx,F,,a Форматируем сектор x и убираем все записи о нем в slip и alt list
При занесении дефектов в slip-list смежные дефекты объединяются в списке.
При этих операциях может возрасти количество ErrCtl, но после передергивания питания
снова 0000.
Я из логов решил попробовать ввести вручную alt-list (который я сбросил, но логи остались)
в slip-list, и на всякий случай после ввода дефектов на одном треке давал форматирование
трека F (точнее я под конец прошелся F по всем трекам, где добавлялись дефекты, хотя думаю,
это не нужно). Правильность занесения проверял сравнением логов T>V1 до и после модификации
slip-list, сохраняя логи в файлы и сравнивая их командой "diff -u".
Одна странность - после Fx,D,,1 по следующей команде <.> видно что сдвигаемся на следующий
трек (только на один, последующие команды F его не меняют), но смежные сектора заносятся
тем не менее верно, даже без промежуточных sx,y.
Еще интересный момент - у меня был подключен и терминал, и IDE кабель, а ALPINE питалась
от отдельного БП. Так вот, после передерга питатния по интерфейсу чтение и верификация OK,
а при записи я получил просто зависание, причем и под FreeBSD, и под DOS (MHDD).
Предполагаю, диск критичен к должному сбросу по интерфейсу, хотя сперва подумал на южный
мост ServerSet CSB5 (ASUS TR-DLS).
Как считаете, правильно ли сделано? Нужен ли дополнительный пересчет транслятора?
У этих семейств он статический или динамический? Если идея правильная, подумаю о
программе, которая будет делать это автоматически. Может быть полезно для дисков 7200.7
с небольшим количеством remap, которые не растут, при общем хорошем состоянии поверхности
(чтобы не гонять долгий SS). Remap-ы эти могут быть зачастую и ложными, от сбоев разных,
но все же надежнее записать их в slip-list...
команд, кстати я нашел эту документацию в нормальном pdf здесь:
http://files.hddguru.com/download/Datas ... 0commands/
Методика ручного добавления дефектов в дефект-листы, в процессе изучения, пока проверялсь
на не сильно нужном barracuda-образном U5 и вышеупоминавшейся PATA ALPINE 80GB, возможны
возможны ошибки в описании. На U5 странности есть (не всегда правильно пишется номер
дефектного сектора (со смещением), но я на нем пока не восстановил ATA overlay, может-быть
из-за этого?).
Есть команда F на уровне 2>, выполняющая форматирование заданного трека или сектора
(она похожа на команду F на уровне 9, которая была у non-barracuda накопителей, U series).
Излагаю в своем переводе, с исправлением ошибки. Дополнения/поправки/замечания приветствуются!
Заданный физический трек заранее нужно выбрать, позиционируя на уровне 2, команда s. Для
7200.9 и новее может понадобиться ключ подтверждения 22, проверяйте правильность
позиционирования по команде <.> Текущий сектор после этого может быть разным, но мы явно
указывем нужный сектор в последующих командах.
Формат команды
Fx,Op,,a
где x - номер сектора, если не введено, форматируем трек (просто F без ничего).
Op - операция (ABDEF)
a - если отсутсвует, то ввводим логический сектор, иначе, если <a> введено (проверял
с 1 и 22), то физический.
Команда 2>F без ключей типа операции и номера сектора форматирует заданный трек (на который
мы позиционировались). При этом slip сектора остаются на своих местах. Происходит ли при этом
частичный пересчет транслятора?
Команда 2>F с отсутствующим ключем операции, но с номером сектора (Fx,,,a) форматирует
сектор x и отмечает его как good (заносит в поля данных сектора правильную ECC?). Удаления
из slip-list этого сектора при этом не происходит.
Команды F с ключами операций:
Op A -> Fx,A,,a Форматируем сектор x и добавляем его в Alt list
Op B -> Fx,B,,a Форматируем сектор x и отмечаем его как плохой (makebad?)
Op D -> Fx,D,,a Форматируем сектор x и добавляем его в slip list (только для UA)
Op E -> Fx,E,,a Форматируем сектор x и добавляем его в slip list (только для SA)
Op F -> Fx,F,,a Форматируем сектор x и убираем все записи о нем в slip и alt list
При занесении дефектов в slip-list смежные дефекты объединяются в списке.
При этих операциях может возрасти количество ErrCtl, но после передергивания питания
снова 0000.
Я из логов решил попробовать ввести вручную alt-list (который я сбросил, но логи остались)
в slip-list, и на всякий случай после ввода дефектов на одном треке давал форматирование
трека F (точнее я под конец прошелся F по всем трекам, где добавлялись дефекты, хотя думаю,
это не нужно). Правильность занесения проверял сравнением логов T>V1 до и после модификации
slip-list, сохраняя логи в файлы и сравнивая их командой "diff -u".
Код: Выделить всё
2>s87ff,1
2>F240,D,,1
2>F241,D,,1
2>F242,D,,1
2>s8801,1
2>Pgm=00 Trk=087FD(08801).1(1).003(138) Zn=4 Err=00 ErCt=0000 Hlth=0000 CHlth=0000 Ready LBA=04348987
2>F2ec,D,,1
2>F2ed,D,,1
2>F2ee,D,,1
T>V1
User Slip Defect List
Num Entries = 069A Checksum = 028E
Total number of Defects = 077F
Hd 0 Span Hd 1 Span
....
....
087FF.1.240 0003
08801.1.2EC 0003
08840.0.076 0001
0893E.1.27B 0001
08B07.1.1CC 000A
....
....
трек (только на один, последующие команды F его не меняют), но смежные сектора заносятся
тем не менее верно, даже без промежуточных sx,y.
Еще интересный момент - у меня был подключен и терминал, и IDE кабель, а ALPINE питалась
от отдельного БП. Так вот, после передерга питатния по интерфейсу чтение и верификация OK,
а при записи я получил просто зависание, причем и под FreeBSD, и под DOS (MHDD).
Предполагаю, диск критичен к должному сбросу по интерфейсу, хотя сперва подумал на южный
мост ServerSet CSB5 (ASUS TR-DLS).
Как считаете, правильно ли сделано? Нужен ли дополнительный пересчет транслятора?
У этих семейств он статический или динамический? Если идея правильная, подумаю о
программе, которая будет делать это автоматически. Может быть полезно для дисков 7200.7
с небольшим количеством remap, которые не растут, при общем хорошем состоянии поверхности
(чтобы не гонять долгий SS). Remap-ы эти могут быть зачастую и ложными, от сбоев разных,
но все же надежнее записать их в slip-list...
-
- Newbie
- Сообщения: 16
- Зарегистрирован: 11.04.2018,21:34
-
- Newbie
- Сообщения: 16
- Зарегистрирован: 11.04.2018,21:34
такое же время как секюритиерайзе
T>/2
2>G7,3
Slip hard errs Enabled Slip soft errs Enabled
Set hlth hard errs Disabled Set hlth soft errs Disabled Stop on hard errs Disabled
Forever Mode write/ read
Pass
18.38-20.00 примерно
80gb
2>G7,2
Slip hard errs Enabled Slip soft errs Disabled
Set hlth hard errs Disabled Set hlth soft errs Disabled Stop on hard errs Disabled
Forever Mode write
T>/2
2>G7,3
Slip hard errs Enabled Slip soft errs Enabled
Set hlth hard errs Disabled Set hlth soft errs Disabled Stop on hard errs Disabled
Forever Mode write/ read
Pass
18.38-20.00 примерно
80gb
2>G7,2
Slip hard errs Enabled Slip soft errs Disabled
Set hlth hard errs Disabled Set hlth soft errs Disabled Stop on hard errs Disabled
Forever Mode write
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Спасибо, запустил 2>G7,3, запись уже прошла, идет чтение.
Хм прошел, и результат несколько неожидан.
Те тест исключил добавленные из бывшего alt-list групповыедефекты на
треке 7D2F, 7D31, и один одиночный на том же 7D31.
Хм прошел, и результат несколько неожидан.
Код: Выделить всё
--- addslip.log 2018-04-26 23:36:41.000000000 +0000
+++ G73test.log 2018-04-26 23:36:55.000000000 +0000
@@ -1,7 +1,7 @@
T>V1
User Slip Defect List
-Num Entries = 069A Checksum = 028E
-Total number of Defects = 077F
+Num Entries = 0697 Checksum = B140
+Total number of Defects = 0777
Hd 0 Span Hd 1 Span
00025.1.0F5 0001
00025.1.0FA 0001
@@ -1452,11 +1452,8 @@
07B65.1.158 0001
07CEF.1.0D1 0001
07D2E.1.2DE 0003
- 07D2F.1.2B4 0003
07D30.1.28A 0003
07D30.1.1D1 0002
- 07D31.1.2A9 0001
- 07D31.1.1A7 0004
07E92.0.0D5 0001
07ED1.0.0C4 0001
07ED6.0.0C3 0001
треке 7D2F, 7D31, и один одиночный на том же 7D31.
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Для лучшего понимания я повторил занесение "удаленных" тестом G7,3 дефектов.
После занесения дефектов и перезагрузки ^C, наблюдал повторяющиеся сообщения:
(первый раз это тоже было, но я подумал, слчайно задел какую-то клавишу).
Они пропали после второго ^C. Что эти сообщения означают?
Пустил заново 2>G7,3. На этот раз ничего не исключилось и не добавилось.
Может даже напутал что в прошлый раз...
После занесения дефектов и перезагрузки ^C, наблюдал повторяющиеся сообщения:
(первый раз это тоже было, но я подумал, слчайно задел какую-то клавишу).
Код: Выделить всё
T>8.01 03-18-05 15:46
(P)PATA Reset
CE Log EC=0 Rtype=36 OV=0 STStatus0
CE Log EC=0 Rtype=36 OV=0 STStatus0
Master
Pgm=00 Trk=0F6BA(0F6BA).0(0).007(006) Zn=0 Err=00 ErCt=0D31 Hlth=0000 CHlth=0000 Ready LBA=03E3F690
Пустил заново 2>G7,3. На этот раз ничего не исключилось и не добавилось.
Может даже напутал что в прошлый раз...
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
KALDYH, Вы не знаете, есть ли возможность у U6 серии просмотреть slip-list (аналог
T>V1 для barracuda)? Именно текущий лист, а не список дефектов в логе SS.
У меня есть U6 одноголовый (20GB) с тремя плохими секторами. Плохие сектора "настоящие", те
коррекция ECC стиранием не помогает, диск делает remap и эти сектора снова попадают alt-list.
Удалось добавить их в slip-list, и избавиться от remap-ов (с помощью команд работы с дефектами, они у U серии отличаются), но правда по моему один дефект я ошибочно добавил,
забыв спозиционировать головку предварительно на нужный трек.
Примерно так
Ну и потом стирание поверхности.
Вообще, после 7200.7-7200.10 как то неудобно:)
T>V1 для barracuda)? Именно текущий лист, а не список дефектов в логе SS.
У меня есть U6 одноголовый (20GB) с тремя плохими секторами. Плохие сектора "настоящие", те
коррекция ECC стиранием не помогает, диск делает remap и эти сектора снова попадают alt-list.
Удалось добавить их в slip-list, и избавиться от remap-ов (с помощью команд работы с дефектами, они у U серии отличаются), но правда по моему один дефект я ошибочно добавил,
забыв спозиционировать головку предварительно на нужный трек.
Примерно так
Код: Выделить всё
1>N07 //смотрим alt-list с помощью SMART
TimeStamp LBA R-Theta-Z
1f6c 2543365 d273-e5da-0
1>/2
2>l254,3365 //конвертируем LBA в CHS
2543365, D273/ 0/ 1D4
2>Sd273,0 //позиционируем на нужный трек и проверяем правильность позиционирования
2>Pgm=50 Trk=D273(D273).0.096 Zn=D Err=00 ErCt=0000 Hlth=0000 CHlth=0000 Ready
2>/9
9>F1d4,D,1 //заносим плохой сектор в slip-list
9>F0,C //чистим alt-list
9>/1
1>N07
TimeStamp LBA R-Theta-Z //alt-list пуст
1>/
T>Intf tsk rst 1024k x 16 buffer detected
ATRst
U6 - ST320410A(A),03.39
.PMstr
Вообще, после 7200.7-7200.10 как то неудобно:)
-
- Newbie
- Сообщения: 16
- Зарегистрирован: 11.04.2018,21:34
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
SRUTSSSSSSSS80, по 7200.7-7200.10 на некоторых дисках я SMART очистил, на
некоторых нет, тк все же хочу найти возможность избирательного сброса атрибута
reallocated sectors, оставив часы работы. и количество start/stop.
На ALPINE (где гонялся G7,3 два раза), SMART сброшен и команды A>P нет.
На TONKA2 A>P уже есть.
Несброшенный SMART кроме ложных показаний reallocated sectors на что-то влияет?
Да и этот атрибут SMART у 7200.7-7200.10 довольно условно отображает содержимое alt-list...
Что касается U6, то у него SMART показания reallocated sectors жестко связаны с количеством
записей в alt-list, и обнуляются при сбросе alt-list (9>F0,C).
некоторых нет, тк все же хочу найти возможность избирательного сброса атрибута
reallocated sectors, оставив часы работы. и количество start/stop.
На ALPINE (где гонялся G7,3 два раза), SMART сброшен и команды A>P нет.
На TONKA2 A>P уже есть.
Несброшенный SMART кроме ложных показаний reallocated sectors на что-то влияет?
Да и этот атрибут SMART у 7200.7-7200.10 довольно условно отображает содержимое alt-list...
Что касается U6, то у него SMART показания reallocated sectors жестко связаны с количеством
записей в alt-list, и обнуляются при сбросе alt-list (9>F0,C).