что можно сказать по этому SMART-у?

Главное, что показл тест? - много блоков с большим временем доступа ....
Не забываем, что whdd считает 1 block = 131072 byte, что равно 256 стандартных секторов/блоков по 512 байт
Ошибки не исчезают с опытом - они просто умнеют
vasek
стандартных секторов/блоков по 512 байт
логических или физических?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
логических или физических?
физических ........ 1 block whdd = 131072 byte
Ошибки не исчезают с опытом - они просто умнеют
vasek
1 block whdd = 131072 byte
да у меня это же пишет. но по факту физический блок 4096, а логический 512
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
по факту физический блок 4096, а логический 512
Тогда проверяй - сложи все показанные (цветные + дефектные блоки) и уможь на 131072 байт --- получишь размер своего диска в байта, дальше можешь поделить на 1024*1024*1024 и получишь размер в G

PS - да, скорее всего логических, а не физических ... совсем забыл, проги считают все в логических ...
отпишись потом - или у тебя данные не сохранились?
Ошибки не исчезают с опытом - они просто умнеют
vasek, завтра сделаю все четко, зная подводные камни...
но прога, по идее, должна обязана учитывать такие факторы.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
В части логических/физических - что то я затупил вчера от этого вопроса. Сам же написал, что блок whdd составлят 131072 байт = 128K ... и он оперирует этим значением без привязки к таким понятиям как логический/физический. Это значение, если мне не изменят память, раньше равнялось (в среднем) размеру дорожки диска.
Ошибки не исчезают с опытом - они просто умнеют
вот как то так:

vasek, твой вердикт, стоит ли такому винту доверить архивы с бекапами?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
стоит ли такому винту доверить архивы с бекапами?

В принципе можно, но есть нюансы, а потому дам расширенный ответ, как это понимаю я.
1. Кандидатов на бэды много - порядка 900. Хоть и много, но по идее нормальный контроллер HDD должен их переварить, сделать ремаппинг - переписать информацию из плохих блоков в резервные, которых несколько тысяч.
В принципе, спецы так и говорят - умный контроллер HDD выполнит всю работу по переназначение плохих блоков сам - не нужно ему мешать.
Добавлю от себя, если для backup, то количество записей на диск будет не таким большим, главное, следить за динамикой изменения атрибутов диска - можно начать с периодичностью раз в 3 месяца, если меняться ничего особо не будет, увеличить до 1 раза в полгода или даже в год, в зависимости от динамики изменения. И в зависимости от динамики изменения атрибутов HDD принимать решение по его дальнейшей эксплуатации ... может проскрипеть еше несколько лет.
Но есть один нюанс, который я и сам не очень хорошо понимаю - 917 есть количество секторов размером по 131072 байт, что составляет 256 логических секторов по 512 байт или 32 физических сектора по 4096 байт.
А какие блоки/сектора указаны в SMART, когда приводится их количество (и плохих и переназначенных)??? и реальное количество резервных болоков - каков их размер??? Для себя считал, что это физические сектора (у меня все диски логический сектор=физическому=512 байт). Никогда в эти тонкости не лез и не разбирался подробно, просто не было для этого случая. Просто веду архив динамики изменения атрибутов диска с самого начала его эксплуатации и этого мне всегда было достаточно.

2. Не плохо бы выяснить местонахождение (LBA) этих кандидатов на бэды … и если они примерно расположены рядышком, а еще лучше если в начале или в конце, то можно эту область отсечь, например создать раздел или по другому.
Но это морока - нужно снова делать тест и следить за ним, выписывая LBA.

3. Но можно попробовать и записать нули, эта опция есть и в whdd. Мнения на этот счет противоречивы - одни пищут помогает, другие - не помогает. В действительности все сложнее. Конечно, если подойти к этому просто, то не помогает. А если обратиться к теории, то бэды то же разные. Если бэды логические - так называемые, soft-bad, т.е. физически исправные сектора, но с ошибками контрольных сумм …. то в этом случае запись нулями исправит эти ошибки, пересчитав контрольные суммы в сбойных секторах. Не буду углубляться в практику, здесь то же могут быть свои нюансы (иногда со временем эти бэды возвращаются).
И еше один нюанс, применив Write Zeros, часть бэдов уйдет и это заметит whdd, но в SMART это не отразится.

Думаю этого достаточно, для размышления. Писал немного сумбурно, возможны не точности, прошу за это не пинать.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Думаю этого достаточно, для размышления.
для размышления достаточно. но хотелось бы услышать ДА или НЕТ. (что ты бы для себя решил бы по этим данным, без гарантий естественно).
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
 
Зарегистрироваться или войдите чтобы оставить сообщение.