nick231
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
[more] Sedin
Цитата:| невозможно придумать какой то там заводской брак.... |
Все пользователи (которые легко находятся по поиску) - сами виноваты и все проблемы от неправильной эксплуатации. И пользователей тысячи. Сам сдавал в обмен два подобных HDD по RMA с софтбэдами и под десяток ремапов в конце HDD что появились буквально за год или два эксплуатации(еще был период с длительной гарантией). Никаких вопросов при обмене не было.
Более чем уверен что если бы здесь 5-я головка была позиционирована на пару нанометров или микрон дальше от поверхности - никаких проблем с ней не было бы.
Предполагаю, что собственная вибрация HDD или вибрация от соседних HDD в корзине приводит головку на грань касания поверхности(самозапил). Что при определенной длительной или интенсивной эксплуатации неминуемо приводит к деградации как самой поверхности так и головки, тем не менее внутренняя фильтрация еще справляется с возникшей пылью и дефекты особо не распространяются на другие поверхности.
С пруфами конечно может сказать только специалист с микроскопом.
По HDD. Сделал стирание начала диска и вообще до середины(не очень понравилось как читалось начало диска) может сам HDD по другому стирает. И запустил продолжение теста с того же места (BA Test SPT Read All). Пошли ремапы(диск так расположен что слышно как дергаются головки, хоть и в тихом режиме AAM) - затем при первом обращении в SA (раньше это действие было ненадолго и далее опять шли ремапы до последнего обращения в SA когда HDD там и завис). Теперь сработал переход по ошибке на 3402 тес. Все вскоре завершилось G лист на удивление был пустой.
Нашел что в конце ранее урезанном от заводского состояния по max LBA(на основе работы с другими HDD упреждающие сразу отрезал ~2 гига от заводского) опять закончились HQ LBA - появились бэды и плохо читаемые сектора.
Уменьшу max LBA еще гиг или больше (лишнее потом вероятно можно будет вернуть).
Чтоб в третий раз корректно продолжить тест с того же места воможно придется восстанавливать модули из бэкапа кроме P-list.
Upd
Четвертый запуск прямо на скан поверхности по LBA прошел успешно(но пока не было обращения к записи логов).
Проблема в запуске была в завышенном HQ max LBA и надо было очистить логи селфскана и только их, больше ничего(ни логи головок ни P, G листы). Обращение к SA во время тестя (видимо для авто переноса G листа в P лист) и продолжение скана с того же места прошло успешно.
Но все же возможно надо делать дополнительное предварительное стирание по крайней мере начала диска(если не было внешнего к скрипту переноса G листа в P лист(который автоматом затирает нужные треки)) перед каждым подобным новом запуске скрипта. Или проверять чтением те места которые уже ремапились чуть ранее(видно по окну статуса и вполне слышно).
Т.е. хотя еще нет точного пруфа(надо зафиксировать явный рост Р листа, забыл сделать скриншот, а т.к. скан переносит иногда целые блоки - они не сильно увеличивают количество бэдов по LBA в P листе - нет существенного роста P листа сразу на тысячи). Если все работает как предполагаю - значит есть возможность автоматического скана по логике (без предварительной очистки P листа). Причем команда BA Test SPT Read All имет ряд параметров (смотреть в B6), которые вероятно еще настраивают чувствительность скана по логике.
Также одновременно в подомном частичном SS скрипте(без удаления P листа) - можно сделать стирание поляны и обновление T листа все в одном. И еще есть такие команда как 1003 - которая, предполагаю также полезна для сокрытия медленных секторов возможно (чистая отсебятина) - она делает синхронизацию треков на основе пропорциональных LBA по головам, но не уверен. Что в теории должно снижать межтрековые задержки времени в блоках LBA ведь в блок LBA при скане большими блоками той же викторией в них 100% попадут сектора с соседних поверхностей, и возможно далеко не соседних треков - что при большом смещении между треками создаст постоянно возникающие медленные межтрековые составные блоки, где быстрые межтрековые блоки - это когда номера треков внутри блока отличаются незначительно.
На ~ пятой итерации процесс переноса (обращения к SA) или сильно задумался или возможно снова подзавис. Может емкость логов маленькая? Или HDD посчитал что-то ошибкой. В 2.3 версии не показывает ошибки. Снова стирать начало поляны и переключаться на демо, для просмотра полного лога если прокатит и не создаст новых ошибок. Прервал SS скрипт. В смарте появились ремапы G листа. Все работает или не очень. Надо было еще подождать, перенос до 15 мин длится, а внутри скрипта сканирования может и дольше. |
Всего записей: 65 | Зарегистр. 31-08-2020 | Отправлено: 15:54 14-09-2020 | Исправлено: nick231, 17:45 14-09-2020 |
|
