| Объявление форума |
Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС. |
Полигон-2 » Технический флейм » Примеры S.M.A.R.T. и сканов HDD / SSHD / SSD с вопросами... |
 |
Примеры S.M.A.R.T. и сканов HDD / SSHD / SSD с вопросами...
... и возможно ответами :-/ Или пытаемся ставить диагноз пацыэнту по фото ;-)
| <<Назад Вперед>> | Страницы: 1 2 3 4 5 6 | Печать |
| CodeMaster
Advanced Member
Рыцарь ордена Хламовников Откуда: Воронеж Всего сообщений: 1655 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 27 авг. 2010 |
KALDYH написал: Могут быть места с ухудшенной читаемостью, где она вытягивается за счёт ECC.Это очень интересная информация. А не встречалась кому блок-схема как firmware винта проводит отбор кантидатов на ремап, их тестирование и собственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)? KALDYH написал: Может компьютер не справляться - при прямом доступе к портам тестирование идёт в режиме PIO, это сильно грузит процессор.Не, там мощные системы, загрузка проца 1%. Я вот как-то тестил винты на буке PIII-500 через переходник в USB 1.1, так вот там видно, что скорость режется на уровне 30 Мбит/с (у HDDScan и того меньше) и загрузка проца 50-90% KALDYH написал: Могут параллельно запущенные процессы сбивать таймер.Тут, кстати, интересный вопрос (вкупе с предыдущим про проц). По идее, тест Verify в HDDScan и Victoria for Win и Линейное чтение (которое раньше и в DOS назвалось верификацией) в Victoria 3.5 проводится firmware винта без участия интерфейса и компа и комп здесь выступает как терминал который выводит собираемую контролером диска информации о скорости доступа. Всё бы вроде так и видно что тесты Read и PIO - чтение идут значительно медленнее, но... тот самый бук PIII-500. Неужели его не хватает для минимальных требований прог тестирования и он не справляется даже с функцией терминала? KALDYH написал: Ну, вообще говоря, плотность записи современных HDD такова, что они даже на громкие звуки реагируютЭто да, но это выглядит как чуть более медленный единичный блок секторов (я же не на вибростенде их проверяю ;-) и на график никак не влияет. KALDYH написал: не говоря уже о положении в пространстве, вибрации,Оно статично. KALDYH написал: атмосферном давлении, температуре и др.Это влияло бы на всё тестирование поверхности. KALDYH написал: А может, причина чисто софтовая, в самом стенде.Может, но вряд ли этот "софтовый" затык может занять 5-10% объёма диска. К данному моменту у меня есть графики тестирования около 20-ти разных дисков и на некоторых я перепроверял подозрительные "впадины" и "пики" и они либо повторяются, либо несколько сглаживаются (в основном провалы) если по этому месту пройтись записью. В данном случае этого не было, да и опять же объём совсем другой это не единичный провал. i8088 написал: В дополнение, еще может быть влияние температуры, чтение может улучшаться/ухудшться при прогреве/охлаждении.Температура у них примерно стабильна, да и тестируются диски более 80 гигов, т.ч. MFM тут не причём. |
| i8088
Advanced Member
Откуда: г. Баку, Азербайджан Всего сообщений: 2132 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 30 янв. 2015 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 31 мая 2018 22:09 Сообщение отредактировано: 31 мая 2018 22:31
CodeMaster написал: обственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)?Так remap при записи и делается, при чтении откладываются кандидаты на remap. CodeMaster написал: проводится firmware винта без участия интерфейса и компа и комп здесь выступает как терминалVerify - это обычная ATA команда, не требующая передачи блока(ов) данных (обычно размер блоков 512 байт). CodeMaster написал: Всё бы вроде так и видно что тесты Read и PIO - чтение идут значительно медленнее,Не понял. Скорость чтения определяется режимом передачи данных и совместной работой диска/ контроллера/драйвера. В режиме PIO4 теоретически достижимый максимум 16.7MB/s с довольно сильной.загрузкой CPU (одного ядра, в случае многоядерных). Верификацию Вы можете проверять даже на 286 машине, на 286 работает например MHDD 2.7.4.3. Те P3-500 не хватить для этого никак не может, ищите причину в ОС и программе. Вообще такие замры идеально под DOS делать... У Seagate Barracuda есть особенность FW - если скорость контроллера менее скорости отдаваеиой диском, то чем быстрее диск мог бы отдать данные, тем медленнее идет чтение. У той же Seagate есть баг, встречается у некоторых семейств - скорость верификации ниже скорости чтения, например ALPINE со старым FW 3.06 на verify дает ~36 MB/s, на чтении ~56MB/s (в начале диска). |
| KALDYH
Advanced Member
Технонекромант Откуда: Кемерово Всего сообщений: 2355 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 5 июня 2009 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 31 мая 2018 22:12 Сообщение отредактировано: 31 мая 2018 22:16
CodeMaster написал: тот самый бук PIII-500. Неужели его не хватает для минимальных требований прог тестирования и он не справляется даже с функцией терминала?Судя по графику загрузки процессора - не хватает. Возможно, просто проги так наговнокодили, возможно, это объективно недостижимо. Скорее всего, там для измерения коротких промежутков времени используются программные задержки вместо системных таймеров. В качестве эксперимента, попробуйте во время верификации параллельно позапускать другие ресурсоёмкие процессы (браузер отлично подойдёт). Как вариант, задать тестовой программе приоритет Realtime - мне очень помогало при поиске медленных секторов с помощью WDMarvel. CodeMaster написал: Это влияло бы на всё тестирование поверхности.Диск имеет зонное распределение. В начале каждой зоны продольная плотность чуть ниже, в конце - чуть выше. В конце зоны канал чтения может и не вытягивать - будет видно как не просто ступенька, а ступенька с "трещинкой". К тому же адаптивное зонное распределение обычно задаёт границы зон, но не число секторов на них, и при не идеальном качестве канала чтения остальные зоны можно сдвинуть вперёд, чтобы уменьшить продольную плотность и уложиться в требования по качеству чтения, а первая зона всегда начинается от начала диска, и её не сдвинешь. Если качество пары головка/пластина чуть ниже проектного, все зоны сдвинутся ближе к началу (краю), а на нулевой появятся провалы чтения. Наблюдал такое не раз на многих винтах, как с заводской разметкой, так и после селфскана. CodeMaster написал: А не встречалась кому блок-схема как firmware винта проводит отбор кантидатов на ремап, их тестирование и собственно ремап (он по возможности происходит с сохранением информации или всегда с потерей)?У меня - только собственные логические измышления по результатам экспериментов и наблюдений за логами терминала. Излагать? По возможности происходит всегда с сохранением информации. i8088 написал: У той же Seagate есть баг, встречается у некоторых семействВстречается, похоже, у многих семейств. |
| i8088
Advanced Member
Откуда: г. Баку, Азербайджан Всего сообщений: 2132 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 30 янв. 2015 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 31 мая 2018 22:30 Сообщение отредактировано: 31 мая 2018 22:31
KALDYH написал: У меня - только собственные логические измышления по результатам экспериментов и наблюдений за логами терминала. Излагать?Да, очень интересно! KALDYH написал: К тому же адаптивное зонное распределение обычно задаёт границы зон, но не число секторов на них, и при не идеальном качестве канала чтения остальные зоны можно сдвинуть вперёд, чтобы уменьшить продольную плотность и уложиться в требования по качеству чтения, а первая зона всегда начинается от начала диска, и её не сдвинешь.Те в результате в основном уменьшится количество цилиндров в первой зоне, а остальные будут сдвинуты вперед? |
| KALDYH
Advanced Member
Технонекромант Откуда: Кемерово Всего сообщений: 2355 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 5 июня 2009 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 31 мая 2018 23:22 Сообщение отредактировано: 1 июня 2018 9:03
Так вот, по алгоритму ремапа. Во-первых, при обращении к сектору проверяется количество попыток повторного чтения и уровней ECC коррекции, и если они выше определённого лимита (пользователю он не виден, но он весьма и весьма высок - будет пытаться не трогать до последнего) - сектор заносится в список кандидатов. При следующей записи в него будет произведён ремап. Во-вторых, винт имеет онлайн-самотестирование SMART (то самое пощёлкивание и жужжание в простое). При этом сканируются отдельные участки поверхности, если найдены бэды - также заносятся в relo-list (терминология WD) "Онлайн" одначает, что BUSY не ставится, и при любом обращении по интерфейсу тест прерывается. В-третьих, в ходе того же тестирования SMART винт пробует снова считать проблемный сектор, и если он наконец считался - ремап будет произведён автономно, незаметно для пользователя. Во всех случаях данные не теряются. Если же битый сектор не читается никак, он так и будет оставаться битым до тех пор, пока пользователь не перезапишет его явно. i8088 написал: Те в результате в основном уменьшится количество цилиндров в первойАга. Не, ну вроде у каких-то более новых появляется адаптивное число секторов в зонах, но это произошло не сразу. Надо на примере сигейтов в таблицах глянуть. |
| i8088
Advanced Member
Откуда: г. Баку, Азербайджан Всего сообщений: 2132 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 30 янв. 2015 |
Спасибо за разъяснения! У меня возник такой вопрос. KALDYH написал: При следующей записи в него будет произведён ремап.А если сектор полностью нормальный, но просто имеет неверную ECC в поле данных, те это обычный soft-bad (UNC-и, которые даже чисто программно легко понаделать)? Узнать soft-bad это или истинный можно же только после записи? При обычном стирании soft-bads исчезают, и remap-a при этом не происходит, уменьшается атрибут Current_Pending_Sector. Я предполагаю, что FW после записи в отмеченный ранее (например в ходе online самотестирования) UNC сектор делает проверку читаемости. И если читаемость восстановлена, и также количество попыток повторного чтения и уровней ECC коррекции в пределах допуска, то remap-а не происходит. Сектор при этом убирается из списка кандидатов на remap. Так ли это? |
| KALDYH
Advanced Member
Технонекромант Откуда: Кемерово Всего сообщений: 2355 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 5 июня 2009 |
i8088 написал: Я предполагаю, что FW после записи в отмеченный ранее (например в ходе online самотестирования)Да, верно. Я об этом забыл. |
| CodeMaster
Advanced Member
Рыцарь ордена Хламовников Откуда: Воронеж Всего сообщений: 1655 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 27 авг. 2010 |
KALDYH написал: Так вот, по алгоритму ремапа."И в дебри сказочной тайги" стали мы углубляться ;-) Но надо, надо подразобраться иначе потом опять об это буду спотыкаться. KALDYH написал: при обращении к сектору проверяется количество попыток повторного чтения и уровней ECC коррекцииЭто проводится "внутри" операции чтения? Т.е. диск считывается, если CRC не совпадает, то пытается восстановить по ECC, если не получилось - чтение повторяется и так сколько-то раз? Это видимо и вызывает цветные сектора при верификации которые в итоге не ремапятся? KALDYH написал: сектор заносится в список кандидатов.Т.е. при этом должной изменить RAW значение атрибута 197? KALDYH написал: Если же битый сектор не читается никак, он так и будет оставаться битым до тех пор, пока пользователь не перезапишет его явно.Т.е. верификация и чтение этого сектора никак не провоцирует firmware к ремапу этого сектора и тесты чтения всегда будут спотыкаться об него и что бы определиться с ним по нему надо пройтись записью? KALDYH написал: Диск имеет зонное распределение. В начале каждой зоны продольная плотность чуть ниже, в конце - чуть выше. В конце зоны канал чтения может и не вытягивать - будет видно как не просто ступенька, а ступенька с "трещинкой". К тому же адаптивное зонное распределение обычно задаёт границы зон, но не число секторов на них, и при не идеальном качестве канала чтения остальные зоны можно сдвинуть вперёд, чтобы уменьшить продольную плотность и уложиться в требования по качеству чтения, а первая зона всегда начинается от начала диска, и её не сдвинешь. Если качество пары головка/пластина чуть ниже проектного, все зоны сдвинутся ближе к началу (краю), а на нулевой появятся провалы чтения. Наблюдал такое не раз на многих винтах, как с заводской разметкой, так и после селфскана.Тут вообще ничего не понял ;-) но это надо переварить и я потом вернусь к этому на примерах графиков (ну или если вы увидете, то скажите). У меня пока только такой вопрос: а по HPA обрезать диск можно только с конца? А через терминал возможны другие варианты? |
| i8088
Advanced Member
Откуда: г. Баку, Азербайджан Всего сообщений: 2132 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 30 янв. 2015 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 3 июня 2018 20:14 Сообщение отредактировано: 3 июня 2018 20:16
CodeMaster написал: Т.е. верификация и чтение этого сектора никак не провоцирует firmware к ремапу этого сектора и тесты чтения всегда будут спотыкаться об него и что бы определиться с ним по нему надо пройтись записью?При верификации сектор может попасть под наблюдение (в список кандидатов на remap). Иначе G-list наполнялся бы soft-bads CodeMaster написал: У меня пока только такой вопрос: а по HPA обрезать диск можно только с конца?Дв. CodeMaster написал: А через терминал возможны другие варианты?Обрезание зон на Seagate не практикуется, но возможно снижение плотности записи в некоторых FW и отключение голов. |
| KALDYH
Advanced Member
Технонекромант Откуда: Кемерово Всего сообщений: 2355 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 5 июня 2009 |
CodeMaster написал: Это проводится "внутри" операции чтения? Т.е. диск считывается, если CRC не совпадает, то пытается восстановить по ECC, если не получилось - чтение повторяется и так сколько-то раз? Это видимо и вызывает цветные сектора при верификации которые в итоге не ремапятся?Да. Но "цветные" сектора это ещё может быть уже сделанный ремап - задержка возникает из-за перемежения в конец диска. CodeMaster написал: Т.е. при этом должной изменить RAW значение атрибута 197?Да. Однако 197 атрибут может также быть с коэффициентом (этот факт я не выяснял) CodeMaster написал: Т.е. верификация и чтение этого сектора никак не провоцирует firmware к ремапу этого сектора и тесты чтения всегда будут спотыкаться об него и что бы определиться с ним по нему надо пройтись записью?Ремап в простое будет произведён, если а) есть время в простое, б) при попытке чтения в это время сектор считался. CodeMaster написал: Тут вообще ничего не понял ;-) но это надо переварить и я потом вернусь к этому на примерах графиков (ну или если вы увидете, то скажите).Ага, чуть позже. CodeMaster написал: У меня пока только такой вопрос: а по HPA обрезать диск можно только с конца? А через терминал возможны другие варианты?Можно. Варианты возможны, но результат тот же. i8088 написал: Обрезание зон на Seagate не практикуетсяВернее, мы не умеем его делать. На старых винтах это работало из-за особенностей структуры микропрограммы. |
| <<Назад Вперед>> | Страницы: 1 2 3 4 5 6 | Печать |
Полигон-2 » Технический флейм » Примеры S.M.A.R.T. и сканов HDD / SSHD / SSD с вопросами... |
|
| 1 посетитель просмотрел эту тему за последние 15 минут |
| В том числе: 1 гость, 0 скрытых пользователей |
| Последние |
|
| [Москва] LIQUID-Акция. Сливаются разъемы CF МС7004 и 7004А на AT и XT Пайка термотрубок Проммать s478 PEAK 715VL2-HT ( Full-Size SBC) Подскажите по 386 материке по джамперам. | |
| Самые активные 5 тем |
|