Полигон-2

Медленно увязаю в болоте диагностики жёстких дисков ;-) До подключения по терминалу не дошёл (да и не всегда это, пожалуй, надо, сначала надо просто отобрать живые диски), но хотя бы более менее начало складываться представление о работе с программами тестирования, однако, вопросов пока меньше не стало. Сначала хотел сгруппировать диски по схожести проблем (вопросов), но потом понял, что ещё не готов ставить точные диагнозы и поэтому пойду по случайной выборке (но начну с вариантов попроще), а походу может, что и будет вырисовываться более структурное.

Используемый софт и получаемые данные.

Основной софт это HDDScan 4.0 (Victoria 4.47 у меня на WinServ 2008 R2 не заработала, и к тому же у HDDScan удобная система сохранения отчётов в html, для выкладывания в интернет), но тут есть некоторые особенности:
1. Значения атрибутов S.M.A.R.T. он выводит в Hex, к этому привыкаешь, но не очень удобно. Поэтому, я буду заострять внимание на тех значения которые у меня вызывают вопросы.
2. График скана поверхности он сохраняет в формате .emf (который например не отображает FF), поэтому я его руками конверчу в .png перед выкладыванием и если вы на странице скана не увидите графика, значит Акелла промахнулся и говорите мне, я сконвертирую файл.
Также иногда будут скриншоты HDDScan с картой тестирования секторов, т.к. там тоже есть некоторые вопросы по "структурам" скоростей доступа к секторам.

Дополнительный софт это Victoria 3.5 for DOS. Т. к. HDDScan не ремапит сектора при верификации, для проблемных дисков я запускаю Victoria на отдельном стенде в режиме линейного чтения с классическим ремапом (пробовал расширенный, но на сильно проблемных дисках он часто срывает крышу то ли Victoria, то ли контроллеру винта). Т. к. это DOS, то с этого стенда будут иногда фотки экрана Victoria с некоторыми вопросами.

Все данные по тестированию будут даны ссылками на .htm страницы или .png или .jpg файлы. Не хочу вставлять картинки в пОсты, это сделает тему компактнее.

Для простоты навигации по теме, у каждого диска будет название типа Disk #XX. Потом я ссылки на пОсты по конкретным дискам, с их номерами попробую подтянуть в подвал первого (этого) пОста, но то ли я не очень понимаю принцип работы ссылок на пОсты на этом форуме, то ли он действительно глючный, не факт, что это будет работоспособно.

Disk #1
Disk #2
Disk #3
Disk #4
Disks #5, #6 и #7

Disk #1 - Hitachi HTS543232A7A384

S.M.A.R.T. | Verify #1 | Verify #2 | Карта блоков

Нулевой атрибут S.M.A.R.T. 5. и ненулевой 196. как бы говорит, что были софт-беды и они исправлены без ремапов, но тест поверхности показывает, что в определённых местах есть провалы. С чем они могут быть связаны? Так получилось, что с первого раза я тестирование закончить не успел и сохранил промежуточные данные test #1 и странно, что на следующий день в test #2 начало диска читается гораздо лучше, при том, что при первом тестировании не было секторов с доступом более 50 мс. Почему данные тестирования могут так плавать день ото дня?

CodeMaster написал:

[q]

Для простоты навигации по теме, у каждого диска будет название типа Disk #XX.

[/q]

Нет. Называй диски так: полное название модели диска_полный серийный номер: WD5000LPVT-22G33T_WD-WX51AA214000. Попадутся два диска одинаковой модели различающиеся только серийными номерами - сам же себе за это потом спасибо скажешь.

CodeMaster написал:

[q]

У меня есть ноут на 32-х битной XP, если что-то надо будет перетестить именно в Victoria, могу запустить там.

[/q]

Диски тестировать надо в открытом корпусе с активным охлаждением оных, никаких ноутов. Аксиома.

нормально виктория 4,47 работает на всех виндах от ХР до 10, 32 или 64 не важно
только на винде 7 и выше надо запускать файл в режиме администратора и будет все ок

CodeMaster написал:

[q]

тест поверхности показывает, что в определённых местах есть провалы. С чем они могут быть связаны?

[/q]

Могут быть места с ухудшенной читаемостью, где она вытягивается за счёт ECC. Может компьютер не справляться - при прямом доступе к портам тестирование идёт в режиме PIO, это сильно грузит процессор. Могут параллельно запущенные процессы сбивать таймер.

CodeMaster написал:

[q]

Почему данные тестирования могут так плавать день ото дня?

[/q]

Ну, вообще говоря, плотность записи современных HDD такова, что они даже на громкие звуки реагируют, не говоря уже о положении в пространстве, вибрации, атмосферном давлении, температуре и др. А может, причина чисто софтовая, в самом стенде.

KALDYH написал:

[q]

Могут быть места с ухудшенной читаемостью, где она вытягивается за счёт ECC.

[/q]

Это очень интересная информация. А не встречалась кому блок-схема как firmware винта проводит отбор кантидатов на ремап, их тестирование и собственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)?


KALDYH написал:

[q]

Может компьютер не справляться - при прямом доступе к портам тестирование идёт в режиме PIO, это сильно грузит процессор.

[/q]

Не, там мощные системы, загрузка проца 1%. Я вот как-то тестил винты на буке PIII-500 через переходник в USB 1.1, так вот там видно, что скорость режется на уровне 30 Мбит/с (у HDDScan и того меньше) и загрузка проца 50-90%


KALDYH написал:

[q]

Могут параллельно запущенные процессы сбивать таймер.

[/q]

Тут, кстати, интересный вопрос (вкупе с предыдущим про проц). По идее, тест Verify в HDDScan и Victoria for Win и Линейное чтение (которое раньше и в DOS назвалось верификацией) в Victoria 3.5 проводится firmware винта без участия интерфейса и компа и комп здесь выступает как терминал который выводит собираемую контролером диска информации о скорости доступа. Всё бы вроде так и видно что тесты Read и PIO - чтение идут значительно медленнее, но... тот самый бук PIII-500. Неужели его не хватает для минимальных требований прог тестирования и он не справляется даже с функцией терминала?


KALDYH написал:

[q]

Ну, вообще говоря, плотность записи современных HDD такова, что они даже на громкие звуки реагируют

[/q]

Это да, но это выглядит как чуть более медленный единичный блок секторов (я же не на вибростенде их проверяю ;-) и на график никак не влияет.


KALDYH написал:

[q]

не говоря уже о положении в пространстве, вибрации,

[/q]

Оно статично.


KALDYH написал:

[q]

атмосферном давлении, температуре и др.

[/q]

Это влияло бы на всё тестирование поверхности.


KALDYH написал:

[q]

А может, причина чисто софтовая, в самом стенде.

[/q]

Может, но вряд ли этот "софтовый" затык может занять 5-10% объёма диска. К данному моменту у меня есть графики тестирования около 20-ти разных дисков и на некоторых я перепроверял подозрительные "впадины" и "пики" и они либо повторяются, либо несколько сглаживаются (в основном провалы) если по этому месту пройтись записью. В данном случае этого не было, да и опять же объём совсем другой это не единичный провал.


i8088 написал:

[q]

В дополнение, еще может быть влияние температуры, чтение может улучшаться/ухудшться при прогреве/охлаждении.
PS. Это явление очень сильно заметно с MFM, у моделей с разомкнутой петлей позиционирования.

[/q]

Температура у них примерно стабильна, да и тестируются диски более 80 гигов, т.ч. MFM тут не причём.

CodeMaster написал:

[q]

тот самый бук PIII-500. Неужели его не хватает для минимальных требований прог тестирования и он не справляется даже с функцией терминала?

[/q]

Судя по графику загрузки процессора - не хватает. Возможно, просто проги так наговнокодили, возможно, это объективно недостижимо. Скорее всего, там для измерения коротких промежутков времени используются программные задержки вместо системных таймеров. В качестве эксперимента, попробуйте во время верификации параллельно позапускать другие ресурсоёмкие процессы (браузер отлично подойдёт). Как вариант, задать тестовой программе приоритет Realtime - мне очень помогало при поиске медленных секторов с помощью WDMarvel.

CodeMaster написал:

[q]

Это влияло бы на всё тестирование поверхности.

[/q]

Диск имеет зонное распределение. В начале каждой зоны продольная плотность чуть ниже, в конце - чуть выше. В конце зоны канал чтения может и не вытягивать - будет видно как не просто ступенька, а ступенька с "трещинкой". К тому же адаптивное зонное распределение обычно задаёт границы зон, но не число секторов на них, и при не идеальном качестве канала чтения остальные зоны можно сдвинуть вперёд, чтобы уменьшить продольную плотность и уложиться в требования по качеству чтения, а первая зона всегда начинается от начала диска, и её не сдвинешь. Если качество пары головка/пластина чуть ниже проектного, все зоны сдвинутся ближе к началу (краю), а на нулевой появятся провалы чтения. Наблюдал такое не раз на многих винтах, как с заводской разметкой, так и после селфскана.

CodeMaster написал:

[q]

А не встречалась кому блок-схема как firmware винта проводит отбор кантидатов на ремап, их тестирование и собственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)?

[/q]

У меня - только собственные логические измышления по результатам экспериментов и наблюдений за логами терминала. Излагать?
По возможности происходит всегда с сохранением информации.

i8088 написал:

[q]

У той же Seagate есть баг, встречается у некоторых семейств

[/q]

Встречается, похоже, у многих семейств.

Так вот, по алгоритму ремапа. Во-первых, при обращении к сектору проверяется количество попыток повторного чтения и уровней ECC коррекции, и если они выше определённого лимита (пользователю он не виден, но он весьма и весьма высок - будет пытаться не трогать до последнего) - сектор заносится в список кандидатов. При следующей записи в него будет произведён ремап.
Во-вторых, винт имеет онлайн-самотестирование SMART (то самое пощёлкивание и жужжание в простое). При этом сканируются отдельные участки поверхности, если найдены бэды - также заносятся в relo-list (терминология WD) "Онлайн" одначает, что BUSY не ставится, и при любом обращении по интерфейсу тест прерывается.
В-третьих, в ходе того же тестирования SMART винт пробует снова считать проблемный сектор, и если он наконец считался - ремап будет произведён автономно, незаметно для пользователя.
Во всех случаях данные не теряются. Если же битый сектор не читается никак, он так и будет оставаться битым до тех пор, пока пользователь не перезапишет его явно.

i8088 написал:

[q]

Те в результате в основном уменьшится количество цилиндров в первой
зоне, а остальные будут сдвинуты вперед?

[/q]

Ага. Не, ну вроде у каких-то более новых появляется адаптивное число секторов в зонах, но это произошло не сразу. Надо на примере сигейтов в таблицах глянуть.

i8088 написал:

[q]

Я предполагаю, что FW после записи в отмеченный ранее (например в ходе online самотестирования)
UNC сектор делает проверку читаемости. И если читаемость восстановлена, и также количество
попыток повторного чтения и уровней ECC коррекции в пределах допуска, то remap-а не происходит.
Сектор при этом убирается из списка кандидатов на remap. Так ли это?

[/q]

Да, верно. Я об этом забыл.

CodeMaster написал:

[q]

Т.е. верификация и чтение этого сектора никак не провоцирует firmware к ремапу этого сектора и тесты чтения всегда будут спотыкаться об него и что бы определиться с ним по нему надо пройтись записью?

[/q]

При верификации сектор может попасть под наблюдение (в список кандидатов на remap). Иначе G-list наполнялся бы soft-bads


CodeMaster написал:

[q]

У меня пока только такой вопрос: а по HPA обрезать диск можно только с конца?

[/q]

Дв.


CodeMaster написал:

[q]

А через терминал возможны другие варианты?

[/q]

Обрезание зон на Seagate не практикуется, но возможно снижение плотности записи в
некоторых FW и отключение голов.

KALDYH написал:

[q]

Можно. Варианты возможны, но результат тот же.

[/q]

В смысле? Можно отрезать начало диска или вырезать кусок в середине?


i8088 написал:

[q]

но возможно снижение плотности записи в некоторых FW и отключение голов.

[/q]

Это пока сложные для меня опции, мне пока по простому ;-) отрезать от такого-то LBA или до такого.

Disk #2 - Hitachi HTS543232L9SA02

S.M.A.R.T. | Verify #1 | Verify #2

Итак, продолжим, ещё один Hitachi тоже на 320ГБ. Похоже на классический вариант ремапа.
По S.M.A.R.T. атрибуты 5. и 196. равны 5 и эти пять секторов с задержками более 1.5 сек можно увидеть в логах скана поверхности (второй короткий тест котрольный, для исключения косяков программы):

[q]

Block start at 13446144 time 1930ms
Block start at 13451264 time 2731ms
Block start at 14041088 time 1640ms
Block start at 14043136 time 1350ms
Block start at 14044160 time 1438ms

[/q]

Они и формируют провал на графике (хотя там рядом с ними полно и других небыстрых секторов)

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

CodeMaster написал:

[q]

Кстати, гладя на 16-тиричное представление атрибута 5. #7FFF могу предположить, что у него закончились разряды для переноса (хотя врядли, конечно, что он вот так прям закончился на последнем плохом секторе).

[/q]

Ну да, разряды закончились. Закончились ли резервные сектора для переноса - не могу сказать. Может, и нет. В принципе, у Тошиб тоже есть терминал, как раз точное число ремапов там и можно глянуть.
Бэдов и "красных" секторов нет? Возможно, тогда действительно резерва хватило в аккурат все сбойные сектора прикрыть, и тогда им в принципе даже можно пользоваться (нужно ли - другой вопрос).

CodeMaster написал:

[q]

Также на графиках видны 2 странные зоны, которые скорее всего образованы софтом или тестовым стендом.

[/q]

Да, похоже на то.

KALDYH написал:

[q]

Бэдов и "красных" секторов нет?

[/q]

Бедов нет, а красных 13 штук (но в "понятиях" Victoria они видимо оранжевыми будут).


KALDYH написал:

[q]

тогда им в принципе даже можно пользоваться (нужно ли - другой вопрос).

[/q]

Ну, если отключить проверку S.M.A.R.T. в BIOS (а то будет постоянная ругань), то можно использовать под игры, а то последние время их менее 50 гигов перестали выпускать и диски быстро заканчиваются.


i8088 написал:

[q]

Почти все Toshiba, что проходили через меня, были в отвратительном состоянии (без remap я вообще их не видел), эти диски действительно некачественные, или мне просто такие попадались?

[/q]

У меня есть Тошибы без ремапов, но глобально о проценте брака судить не возьмусь. У меня больше вопросов Fujitsu вызывают, но миожет просто потому, что они все очень медленные.

CodeMaster написал:

[q]

Disk #4 - Hitachi HTS543232L9SA02

[/q]

Поправьте

CodeMaster написал:

[q]

Как видно по скану поверхности он редкий тормоз в сравнении с аналогами от других производителей.

[/q]

Дык 80 Гб. Он ровесник Барркуд 7200.9, только скорость при этом 5400 об/мин.

CodeMaster написал:

[q]

1. Такие программные сбои в S.M.A.R.T. лечатся?

[/q]

Сбросить его будет довольно затруднительно - фришного софта по ним я не знаю. Можно через терминал маленько поковырять, но возможности довольно ограничены.

CodeMaster написал:

[q]

4. Ну, и вопрос на засыпку: на задержки с доступом к нулевому сектору можно забить? С одной стороны это может быть инерция механики, но с другой стороны верификация должна начаться только после того как блок головок установится на нулевую дорожку и прочитает нулевой сектор :-/

[/q]

Да, это инерция механики. Забить. По умолчанию во всех винтах после рекалибровки головка находится где-то в середине диска. Измерение времени доступа к сектору (вернее, к блоку - как я понял, проги используют Block Mode) начинается сразу от подачи команды.

На 2 и 3 вопрос ответов не знаю.

Вот скрипт есть: http://forum.ru-board.com/topi...;start=0#7
Осталось понять, в чём он выполняется. Возможно, в PCHDD.
К сожалению, у меня нет на руках более-менее живых Fujitsu ARM, чтобы поэкспериментировать.

CodeMaster написал:

[q]

Просто, для сравнения. Очень лаконичный S.M.A.R.T., тревожный атрибут 199.

[/q]

Картинка у меня не открылась, но этот атрибут информационный, означает что диск работает
(работал) в проблемной системе. Он может просесть до критического просто даже от ошибке в
драйвере/BIOS, причем очень быстро! (У меня было такое). На надежность работы после устранения
внешней проблемы (атрибут должен перестать расти) не влияет.

И еще один момент - если какой-то атрибут имеет огромное значение и близкое к степени 2 (как на
Вашей Toshiba), то это может быть сбоем SMART, счетчик изменился в обратную сторону. Так на
обеих приобретенных мной TONKA2 (одна SATA, а другая PATA) были одинаковые и огромные значения
атрибутов 197 и 198, на одном 2^32-1, на другом 2^32-2. Поверхность у обеих дисков хорошая, а
ересь в этих атрибутах удалось сбросить, сохранив остальные атрибуты.

Вот что было:

197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       4294967295
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       4294967295



CodeMaster написал:

[q]

Я про сравнение с аналогичными по объёму (хотя, тут важнее наверное плотность записи, а она может же отличаться у разных производителей,

[/q]

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

11 серверных 2.5 дисков ST95000NSSUN500G с наработкой over 50K часов. При этом диски в весьма бодром состоянии. У нескольких есть немного ремапов и у них же видимо начала плыть механика, т.к. появились "пилы" на графиках чтения.

Disk #8

S.M.A.R.T. | Verify | Карта блоков начало | Карта блоков конец

Disk #9 - идеальный график по зонам.

S.M.A.R.T. | Verify

Disk #10 - "пила" в начале и чуть в конце и видимо ремап неспроста.

S.M.A.R.T. | Verify

Disk #11 - лёгкая "пила" в начале.

S.M.A.R.T. | Verify

Disk #12 - ещё один близкий к идеалу.

S.M.A.R.T. | Verify

Disk #13 - довольно много ремапов. Ими видимо и обусловлен провал на графике.

S.M.A.R.T. | Verify | Карта блоков начало | Карта блоков конец

Disk #14 - ремапы, "пила" в начале.

S.M.A.R.T. | Verify

Disk #15 - тоже самое.

S.M.A.R.T. | Verify

Disk #16 - побольше ремапов, сильнее "пила".

S.M.A.R.T. | Verify

Disk #17 - почти идеал.

S.M.A.R.T. | Verify

Disk #18 - ремапы, пила.

S.M.A.R.T. | Verify

CodeMaster написал:

[q]

ST9160823ASG

[/q]

Galileo... Редкий зверь. Я бы ему в терминал заглянул, и посмотрел бы реальные дефект-листы. Может, дефектов и нет на самом деле - но тогда непонятно, почему так странно составлен транслятор...

CodeMaster написал:

[q]

"пилы" на графиках чтения.

[/q]

Присмотрелся. Всё в порядке. Это переключение с головки на головку. Особенность дисков высокой плотности - переключение головок (и последующий захват синхронизации, смена настроек канала чтения-записи и т.д.) занимает больше времени, чем переход на соседнюю дорожку. Поэтому головки переключаются реже, чем на дисководах и старых винчестерах - сначала читается ряд соседних дорожек, потом возврат головки назад и ряд дорожек по другой головке, и т.д. Реальные алгоритмы порядка чтения блоков ещё сложнее, но не суть. А суть в том, что с развитием адаптивного форматирования на разных поверхностях появилась разная плотность записи. И при переключении головок из-за этого появляется пила - одна поверхность быстрее, другая - медленнее. В общем, графики серверных дисков соответствуют вполне здоровым винчестерам, это фича.

CodeMaster написал:

[q]

В этом смущает, то что "пила" не по всему диску, а обычно в начале и возможно в конце.

[/q]

А в середине, значит, плотности поверхностей совпадают.

CodeMaster написал:

[q]

просто заметил некоторую зависимость между "пилой" и ремапами

[/q]

Есть ещё "шумподобный" график...

CodeMaster написал:

[q]

Galileo это "G" в конце?

[/q]

Нет, это Momentus 7200.2. Что означает G в конце - не знаю.

Disk #24 - Seagate ST95005620AS

S.M.A.R.T. | Verify

"Коллега" дисков #5 и #6, в том смысле что тоже Seagate и также 500-тка, но совсем другой серии "Momentus XT". Первый раз встречаю такой. График чтения вроде бы отличный, есть чутка небыстрых секторов, но главный вопрос это показатели S.M.A.R.T. они слишком идеальные, в т.ч. время работы всего 7 часов. То ли мне попался совсем новый диск, то ли S.M.A.R.T. сбросили :-/

Одной головке явно нехорошо.

CodeMaster написал:

[q]

Или у них как у магнитофонов раздельные головки записи и чтения?

[/q]

Для записи индуктивная, для чтения MR головка (так не всегда было, старые диски использовали общую индуктивную головку).

Кроме того, диск обычно не проверяет запись (если только сектор не в списке "подозрительных"). Вспомните MFM, диск может отлично
форматироваться, а при чтении беды полезут. Те для того чтобы запись посчиталась успешной, в основном достаточно иметь
читающиеся сервометки, корректные идентификаторы секторов, транслятор.

CodeMaster написал:

[q]

А как ты это определил, что именно голове и именной одной, по "волнам"?

[/q]

При чтении головки чередуются. На карте это видно как периодические медленные поля блоков (на графике не столь заметно).

KALDYH написал:

[q]

При чтении головки чередуются.

[/q]

А зачем, из-за плотности соседних дорожек? Параллельно чтение было бы быстрей.

Disk #26 - Seagate ST9120817AS

S.M.A.R.T. | Verify 1 | Verify 2 | Write

Диск с проблемами похожими на предыдущий: те же "волны" (но с меньшей "бальностью" ;-), та же кардиограмма на графиках верификации (в Victoria так вообще ужОс какой-то ;-), тот же красивый график на запись, но есть и отличия:
1. S.M.A.R.T. походу чутка поломан (на атрибуты .240-.242 внимание обращать не стоит, они на многих похожих Seagate в подобном состоянии (правда встречаются и в нормальном)) - атрибуту .4 явно не хорошо, ибо я не представляю как можно вкл./выкл. диск 750 тыс. раз. да ещё за 12 тыс. часов. Получается его включали каждую минуту.
2. Атрибут .196 большой, но атрибут .5 в нулях видимо эти софт-ББ возникают из-за этих проблем с головой (у предыдущего диска почему-то нет атрибута .196 вообще, поэтому х.з. есть ли в этом общая тенденция)
3. Графики верификаций не совпадают между собой. При том, что и задержки в блоках не критичные и вообще их не так много про сравнению с предыдущим диском. Не знаю как это можно объяснить :-/ может это и не проблемы с головой или не с одной или ещё какой-то переменчивый дефект.

CodeMaster, явно не задействован UDMA, идёт обмен через PIO. Копайте в сторону настроек материнки, операционной системы, драйверов IDE/SATA контроллера и жёсткого диска.

Disk #28 - Hitachi HTS727550A9E364

S.M.A.R.T. | Verify | Read | Write | HD Tune Read | HD Tune Write

Попались тут мне пара данных дисков недавно, и их графики оказались одновременно и подозрительно одинаковыми и подозрительно странными. Потом я посмотрел графики других дисков Hitachi от 250 гигов и выше и если вообщем их охарактеризовать, то все они как будто нарисованы пьяной рукой ;-) Причём этот тремор увеличивается с ростом ёмкости и хотя, степень опьянения сильно различается для разных дисков даже одной серии (и даже на одном диске может сильно отличаться по поверхности), но по большому счёту у ёмких бучных Hitachi не бывает гладкого или ступенчатого графика. С чём это может быть связано?
Замечания:
1. Рисунок графиков стабилен при повторных тестах;
2. Рисунки графиков верификации, чтения и записи в HDDScan сильно различаются (при чтении он почти нормальный);
3. Рисунки графиков чтения и записи в HD Tune похожи между собой и похожи на верификацию HDDScan (что ещё больше запутывает логику).