Можно ли доверять smartctl?

Почему в отчёте столько префейлов?

Вопрос на 5 звёзд.

Ничего, что это колонка type?

Потому что забаньсядебил. Pre-fail - это ТИП параметра (если он станет ниже порогового значения, значит, скоро будет fail).

Общее правило расшифровки SMART, сравниваешь VALUE с THRESH поглядывая на WORST, чем ближе VALUE к THRESH, тем больше поводов для беспокойства по конкретному атрибуту.

Критичные атрибуты: (Pre-fail)
Некритичные атрибуты: (Old_age) (величина value отведенная вендором до
наработки на отказ (ресурс)).
Если VALUE стало меньше THRESH в случае Pre-fail атрибута - существует
большая вероятность, что диск вылетит в ближайшие 24 часа.

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

Главное, не обращать внимание на колонку RAW_VALUE, где производитель хранить может что угодно, хоть текущую дату по календарю шумеров.

смарт идеальный, почти.
UDMA_CRC_Error_Count 760
кабель хреновый?

Охренеть. Век живи, век учись.

вот прям вообще у всех параметров?

Вот тоже не пойму, походу разъем в матери, мать дурацкая или корпус, разъмы смотрят не наверх а в сторону корзин, сверху зажаты видеокартой, с другой стороны зажаты винтами. Уже шнурков 5 поменял и в разные разъёмы втыкал, результат один и тот же.

Base Board Information
	Manufacturer: Gigabyte Technology Co., Ltd.
	Product Name: 990XA-UD3
	Version: To be filled by O.E.M.
	Serial Number: To be filled by O.E.M.
	Asset Tag: To be filled by O.E.M.
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: To be filled by O.E.M.
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

На практике для тех же сбойных секторов пишут реальное значение (хотя, кто его знает, может уже для каких SSD/SHDD это и не так). Но это не требуется стандартом. Поэтому те же сигейты знамениты огромными цифрами в 1 параметре и так далее.

большинство атрибутов это накопительный счетчик
на практике raw-значение содержит его текущее значение

На практике, как минимум, 1,3,7,195,199 содержат что бог на душу положит. И даже те, кто на вид выглядят накопительными счётчиками, не факт, что таковыми являются, стандарт этого не гарантирует. А, даже когда они таковыми действительно являются, не зная калибровочных значений никаких выводов из них сделать нельзя. Не читайте до обеда RAW_VALUE. И после обеда не читайте.

Поэтому те же сигейты знамениты огромными цифрами в 1 параметре и так далее.

У тех сигейтов эти «огромные» цифры декодируются в пару вполне понятных значений. Надо «просто» где-то найти спецификацию для конкретного винта, а может дажи и конкретной фирмвари.

Действительно, проще на RAW_VALUE вообще не смотреть.

У меня вот был диск wd green, как у многих, наверное. Он стал нещадно тупить и бить данные, сначала количество reallocated росло, потом offline uncorectable пошли, но в состояние failing смарт так и не выпал. Спрашивается, зачем нужна такая самодиагностика, и как после этого верить нормализованным значениям?

У меня вообще за всю жизнь только 1 диск показал смерть по смарту, и тот был новым, проработал всего дней пять. Все остальные становились неюзабельными раньше, чем смарт раздуплялся. Может быть, с серверными дисками ситуация лучше, но на бытовых смарт отрабатывает как от него ждёшь примерно никогда.

1,3,7 это не те атрибуты которые можно назвать накопительный счетчик
в 199 вполне осмысленное значение,
а также в счетчиках секторов, температуры, часов работы, вкл/откл...

но в состояние failing смарт так и не выпал

а он и не выпадает, пока значения не перелезут через THRESH

Может быть, с серверными дисками ситуация лучше

у меня есть WD GOLD-ы и HGST-ки, в которых 1000++ переназначенных секторов, но нормализованное значение не превысило порог и смарт говорит все ОК. =)

Диск тупит и постоянно бьёт данные. Им объективно нельзя нормально пользоваться. Может быть должна быть характеристика получше, чем просто количество переназначенных секторов?
Мне лично пофиг, по какому параметру он в failing вывалится, но лучше бы это случилось до того, как он перемелит все данные в труху. И дело в отсутствии бэкапов, а в том что ты бэкапы будешь делать с уже битых данных.

Тут мастера чтения смарта всякого написали... На самом деле смарт оценить проще по колонке raw, главное понимать значение параметров 1, 5, 7, 194, 196, 197, 198, 199. По данному примеру очевидно требуется замена шлейфа. И разобраться почему он нагревался до 54 градусов, дабы исключить системность подобных приключений для него.

В жизни не видел чтобы умирающий диск не дал ясной картинки по raw, а насмотрелся я разного...

сначала количество reallocated росло, потом offline uncorectable пошли

Типичная картина трупа. Диагностика так и делается. Пошли пендинки и/или релоки, диск - труп. Может побрыкаться, но в целом обратной дороги нет.

Параметры смарта имеют своё значение, если не пытаться передожить ответственность на железяку, а понять картину происходящего из нескольких параметров и их динамики, вопросов не будет

Тут выше утверждают, что на RAW_VALUE смотреть и делать из него какие-либо выводы нельзя. Если THRESH не достигнут, значит все ок.

Да, кстати, я знаю, что всякие raid-контроллеры полных данных по smart дисков не отдают, только состояние жив/мёртв. Как же с ними живут? Наверное все-таки у нормальных дисков диагностика лучше настроена.

Они начитались тупых гайдов в интернете, скорее всего. Смотреть надо в raw, понимать значение параметров, понимать как утроен диск. Ещё раз говорю, за 15 лет в IT через меня прошло несметное кол-во дисков, многократно ловил предсмертные муки в смарте, ещё большее кол-во готовых трупов видел. По raw всегда ясно читалась картина что происходит/произошло.

На самом деле смарт оценить проще по колонке raw

Вот, какая будет ваша оценка:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE                                                            
  1 Raw_Read_Error_Rate     0x000f   105   079   006    Pre-fail  Always       -       10036943                                                             
  3 Spin_Up_Time            0x0003   095   095   000    Pre-fail  Always       -       0                                                                    
  4 Start_Stop_Count        0x0032   094   094   020    Old_age   Always       -       6398                                                                 
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0                                                                    
  7 Seek_Error_Rate         0x000f   085   060   030    Pre-fail  Always       -       372566484
  9 Power_On_Hours          0x0032   061   061   000    Old_age   Always       -       34225
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0

Это обрубок которым можно жопу подтереть.

Слив засчитан.

На самом деле:

• Raw_Read_Error_Rate: 0 errors in 10,036,943 operations
• Seek_Error_Rate: 0 errors in 372,566,484 operations

Иди ещё где-нибудь поперди в лужу школота, скучно. А лучше почитай учебник формальной логики, подтирать жопу законом тождества нехорошо.

Надо знать особенности диагностируемого диска. И учитывать это.

10036943

Это число кодируется явно меньше наибольшего 48-битного числа (или сколько там битов приходится не на ошибки), а значит всё хорошо. Было бы оно больше 281474976710655, тогда ой. Сигейт?

Только на raw всегда и смотрю.

Сигейт?

Конечно, про них же речь была выше.

Тебе, пятизвёздочному олигофрену, пытаются сказать, что «смотреть на RAW» не зная хотя бы производителя (а лучше модель) — бесполезно, поскольку оно vendor-specific. Но тебе, с опытом работы в говноконторе «рИмАнТиРуИм фСё», конечно, виднее.

не зная хотя хотя бы производителя (а лучше модель)

Я тебя анонимного гипоэнцефалокрана удивлю, но в выхлопе smartctl есть эта инфа.

Но тебе, с опытом работы в говноконторе «рИмАнТиРуИм фСё», конечно, виднее.

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