Полигон-2

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 (дальше будут ещё примеры). Что это такое, это особенности расчёта скорости доступа к блоку программами и проявления какого-то не совсем корректного округления на границах блоков или это явление имеет физическую основу на поверхности пластины?

Disk #3 - TOSHIBA MK6476GSX

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

Раз по предыдущему диску особых комментариев не было, продолжим. Теперь это диск Toshiba со статусом S.M.A.R.T. = BAD. Как видно из S.M.A.R.T. атрибут 5. имеет RAW значение 32767 ремапа и при этом его значение упало до 1. Кстати, гладя на 16-тиричное представление атрибута 5. #7FFF могу предположить, что у него закончились разряды для переноса (хотя врядли, конечно, что он вот так прям закончился на последнем плохом секторе). Также необычно, что у этого S.M.A.R.T. нет атрибутов 196. и 197. Но есть .199 значение которого пока не совсем понятно, если у него связь с ремапами или нет. На первый взгляд это "ж-ж-ж" не спроста, но однозначной зависимости пока не увидел.
На графиках видны 4 чётких провала, провалы образованы не очень медленными секторами, как в предыдущем диске, но большим их количеством. Причём, учитывая почти одинаковую "глубину" провалов в парах, могу предположить, что это перенос секторов в более медленные зоны (на графике второго теста я начертил свою идею). Также на графиках видны 2 странные зоны, которые скорее всего образованы софтом или тестовым стендом. На первом это ограничение в начале скорости доступа на уровне 70 МБ/с, на втором тоже ограничение скорости, но не фиксированное, а пропорциональное около 10% от нормальной и расположено оно в другом месте.