проверка HDD badblocks vs smartctl - кому верить?

1 23
vlad0708
На сайте с 18.09.2008
Offline
120
#21
seocore:
да и не стоит забывать, что когда диск натыкается на такие нестабильности, то "подвисает" вся система, тот же LA уйдет за сотню 😂

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

Это в теории.

На практике так?

seocore
На сайте с 25.09.2006
Offline
143
#22
vlad0708:
насколько я понял из обилия прочитанной информации, диск не натыкается на такие нестабильности, он их "прячет в уголок" и забывает про них.
Это в теории. На практике так?

на практике - поверхность деградирует дальше, диск натыкается на новый нестабильный участок, пытается с него прочесть информацию (десятки и сотни раз прочитывая этот сектор), после чего электроника принимает решение, что этот сектор пора утилизировать (секторов в запасе под утилизацию тоже не так много как кажется), как этот процесс визуально выглядит? - в системе резко возникают проблемы с iowait, LA моментально уходит на несколько десятков единиц, какая может быть при этом стабильная работа? 😂

да и еще пара моментов, на заводе производится анализ поверхности, и пометка нестабильных секторов (скрытая таблица), после чего обнуляется SMART (в т.ч. на так называемых дисках с "заводским восстановлением"), и если у вас с самого начала в SMART'е есть какие-то данные, то диск не новый, пусть хоть из коробочки запечатанный, но не новый, и не важно какие там сказки рассказывал вам продавец

Инструменты для веб-мастера: кластеризатор СЯ (https://goo.gl/MQWfqO), все запросы конкурента (https://goo.gl/hd5uHS), дешевые XML-лимиты (https://goo.gl/aDZbPI)
AboutSEO
На сайте с 18.01.2007
Offline
154
#23
seocore:
...(секторов в запасе под утилизацию тоже не так много как кажется)....

ну это смотря что считать "не так много".

вот к примеру у меня есть один


5 Reallocated_Sector_Ct 0x0033 084 084 010 Pre-fail Always - 679
196 Reallocated_Event_Count 0x0032 084 084 000 Old_age Always - 679
197 Current_Pending_Sector 0x0012 100 089 000 Old_age Always - 0

и если отталкиваться от 084 084 010, для 679 бэдов это получается примерно 42 бэда на 1 пункт VALUE / WORST.

и только когда WORST достигнет 010, то только в этом случае будет считаться, что веник убит, а это будет аж как минимут 3780 бэдов.

это пример для веника SAMSUNG HD753LJ на 750гигов.

1 23

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий