Полигон-2

Спасибо за разъяснения!

У меня возник такой вопрос.

KALDYH написал:

[q]

При следующей записи в него будет произведён ремап.

[/q]

А если сектор полностью нормальный, но просто имеет неверную ECC в поле данных, те это
обычный soft-bad (UNC-и, которые даже чисто программно легко понаделать)? Узнать soft-bad
это или истинный можно же только после записи?

При обычном стирании soft-bads исчезают, и remap-a при этом не происходит, уменьшается
атрибут Current_Pending_Sector.

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

KALDYH написал:

[q]

Так вот, по алгоритму ремапа.

[/q]

"И в дебри сказочной тайги" стали мы углубляться ;-) Но надо, надо подразобраться иначе потом опять об это буду спотыкаться.


KALDYH написал:

[q]

при обращении к сектору проверяется количество попыток повторного чтения и уровней ECC коррекции

[/q]

Это проводится "внутри" операции чтения? Т.е. диск считывается, если CRC не совпадает, то пытается восстановить по ECC, если не получилось - чтение повторяется и так сколько-то раз? Это видимо и вызывает цветные сектора при верификации которые в итоге не ремапятся?


KALDYH написал:

[q]

сектор заносится в список кандидатов.

[/q]

Т.е. при этом должной изменить RAW значение атрибута 197?


KALDYH написал:

[q]

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

[/q]

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


KALDYH написал:

[q]

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

[/q]

Тут вообще ничего не понял ;-) но это надо переварить и я потом вернусь к этому на примерах графиков (ну или если вы увидете, то скажите). У меня пока только такой вопрос: а по HPA обрезать диск можно только с конца? А через терминал возможны другие варианты?

CodeMaster написал:

[q]

Это проводится "внутри" операции чтения? Т.е. диск считывается, если CRC не совпадает, то пытается восстановить по ECC, если не получилось - чтение повторяется и так сколько-то раз? Это видимо и вызывает цветные сектора при верификации которые в итоге не ремапятся?

[/q]

Да. Но "цветные" сектора это ещё может быть уже сделанный ремап - задержка возникает из-за перемежения в конец диска.

CodeMaster написал:

[q]

Т.е. при этом должной изменить RAW значение атрибута 197?

[/q]

Да. Однако 197 атрибут может также быть с коэффициентом (этот факт я не выяснял)

CodeMaster написал:

[q]

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

[/q]

Ремап в простое будет произведён, если а) есть время в простое, б) при попытке чтения в это время сектор считался.

CodeMaster написал:

[q]

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

[/q]

Ага, чуть позже.

CodeMaster написал:

[q]

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

[/q]

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

i8088 написал:

[q]

Обрезание зон на Seagate не практикуется

[/q]

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

CodeMaster написал:

[q]

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

[/q]

Не, нельзя. Это было бы как раз то самое "исключение зон".

Кстати,ещё вопрос по карте блоков Disk'а #1 который забыл спросить. На скриншоте видно, что после блоков со временем доступа 50 и 20 мс идут 2-3 особо быстрых блока по 5 мс. (которых, кстати, на этом диске в принципе мало). Этот эффект я называю "тень" ;-) он повторяется на разных дисках и разных прогах (например в Victoria for DOS (дальше будут ещё примеры). Что это такое, это особенности расчёта скорости доступа к блоку программами и проявления какого-то не совсем корректного округления на границах блоков или это явление имеет физическую основу на поверхности пластины?