Pull to refresh

Comments 16

С учетом, что способ получения атрибутов стандартен, сами атрибуты стандартны и от диска к диску меняется лишь набор поддерживаемых — какая smartmon'у разница, что там вообще за диск? И зачем ему эта drivedb?
сами атрибуты стандартны и от диска к диску меняется лишь набор поддерживаемых

нет.


И зачем ему эта drivedb?

в первую очередь, как раз, для корректной обработки атрибутов smart, специфичных для накопителей.
и да, это касается только sata (и, может быть, ide). у sas и nvme другой smart.


opensource же, кто вам мешает заглянуть что там внутри?
https://www.smartmontools.org/browser/trunk/smartmontools/drivedb.h

Так я взглянул. Не вижу, как отсуствие того или иного накопителя в этом файле может помешать программе показать smart. В худшем случае — без расшифровки raw значений.

не может помешать, соглашусь. а для nvme тем более.


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

К сожалению, для SSD (если это не NVMe) нет стандартных атрибутов которые показывали бы реальное состояние "здоровья", у каждого вендора (а иногда и у каждой линейки моделей) свои и часто несовместимые — именно для этого и нужна drivedb — если заглянете туда, увидите что в некоторых устройствах одно и то же значение имеет разные id и иногда даже отличается семантика.


Простой пример — у Samsung атрибут 177 — Wear Leveling Count (не у всех моделей), у SanDisk и у Kingston его скорее не будет (тоже зависит от модели). Просто пройдитесь smartctl по разным вендорам SSD — сразу станет ясно что нет ничего стандартного.


Впрочем, даже если атрибуты известны — они не всегда отражают реальность, по моему опыту SSD почти всегда умирают внезапно — т.е. вплоть до смерти всё ок по всем атрибутам, потом вдруг "ой всё", иногда задолго до исчерпания паспортного ресурса. Чаще всего такое происходит с обычными потребительскими моделями (уже стопочка SanDisk и Kingston), но и суровые датацентровские (Samsung DCT) тоже не исключение.


Ситуация усложняется тем что не все вендоры (и не для всех моделей) публикуют информацию об атрибутах, поэтому при их чтении smartctl получаем вот такое (со свежей drivedb и накопителем Kingston которому уже минимум года два):


201 Unknown_SSD_Attribute   0x0023   100   100   005    Pre-fail  Always  -    100
240 Unknown_SSD_Attribute   0x0032   100   100   000    Old_age   Always  -    5922

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


Бывает и наоборот — смарт во всю жалуется что "всё пропало", но накопитель работает без проблем ещё пару лет (уже перемещённый в некритичную систему, ради эксперимента).


Так что ситауция мало изменилась по сравнению с обычными HDD — smart наверное лучше чем без него, но его "надёжность" всё ещё на уровне бросания монетки (по крайней мере для SATA/SAS, по NVMe у меня ещё нет статистики).

К сожалению, для SSD (если это не NVMe) нет стандартных атрибутов которые показывали бы реальное состояние "здоровья", у каждого вендора (а иногда и у каждой линейки моделей) свои и часто несовместимые — именно для этого и нужна drivedb — если заглянете туда, увидите что в некоторых устройствах одно и то же значение имеет разные id и иногда даже отличается семантика.

smartctl -l ssd /dev/sda

работает вроде бы на всех, попадающихся в руки.


Впрочем, даже если атрибуты известны — они не всегда отражают реальность, по моему опыту SSD почти всегда умирают внезапно — т.е. вплоть до смерти всё ок по всем атрибутам, потом вдруг "ой всё", иногда задолго до исчерпания паспортного ресурса

скорее дело в неправильной трактовке показаний smart.
«процент износа» не показывает насколько здоров диск, он показывает сколько процентов из расчётного ресурса израсходовано (например, память рассчитана на 1500 циклов erase, а было произведено 500, износ 33%). и этот процент вполне может быть больше 100.
но некоторые накопители блокируют запись на диск после некоторого превышения объёма записи на диск.


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


но и суровые датацентровские (Samsung DCT) тоже не исключение.

честно говоря, я не почти сталкивался с выходом dc накопителей из строя, на памяти всего два случая:


  1. накопитель (ЕМНИП micron 5200 или 5300) начал «жаловаться» на перегрев, через несколько часов перестал работать. что именно произошло неизвестно, это был дедик в дц хостера, хостер просто заменил накопитель;
  2. буквально сегодня, читая именно это статью, я решил проверить рукой температуру моего домашнего samsung pm963 и он сдох. судя по следам, smd-элемент замкнул на массу на китайской плате-переходнике (там был очень небольшой зазор, от прикосновения плата накопителя чуть прогнулась и здравствуй, КЗ).
    image

Жалоба от производителя оборудования на то, что в Linux нет драйвера для этого оборудования.


Странно, но мне кажется, что всё в ваших руках.

Упс... Всегда забываю что есть бенчмарки для накопителей. Проведу-ка профилактику на досуге)

Я чего-то не понял: в корпоративном блоге Kingston идёт жалоба на то, что в Linux нет нормальных дров на SSD от того же самого Kingston? Странная, однако, вещь)

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

Kingston вы опять обделались..

С момента покупки прошло уже два года, а по данным CrystalDiskInfo остаток ресурса составляет всего 87%.

так «уже два года» или «всего 87%»?


Но температура платы достигала 70°С в пиковые моменты, что много для чипов памяти.

не температура платы, а температура контроллера. температура чипов памяти обычно сильно ниже температуры кон


И главное, почему установленный через терминал Smartmontools выдает ту же ошибку доступа к данным самодиагностики?

ту же — это какую? не вижу в статье ни параметров запуска smartctl, ни полученного ответа, вижу лишь стенания «ах, мы не умеем линукс» и куча каких-то скриншотов.


мне известны два способа чтения данных смарта с nvme-накопителей:


smartctl -x /dev/nvme0n1

и


nvme smart-log /dev/nvme0n1

оба у меня работают со всеми имеющимися накопителями.


Момент установки был волнителен как никогда.

читается как захватывающий детектив (нет)


Со второго прогона, выставив размер файла 0.5 ГБ, диск показал практически паспорт

у вас ещё и с русским всё плохо (диск выставил размер файла?)


Какие итоги мы смогли вынести из увиденного?

не пишите больше статьи на хабр.

Я вот так и не понял при каком условии из SMART данных надо срочно менять накопитель? Какой триггер? Какая метрика говорит что диск протянет не более месяца и в ближайшее время двинит кони вместе со всеми данными?

Обычно большинство пользователей забывает, что SSD (а также NVMe) надо охлаждать с обеих сторон. Тогда и не будет внезапных отказов.

Этим должен заниматься не пользователь, а тот кто это проектирует.

зачем? тем более с двух сторон.


  1. флэш не особо греется при работе;
  2. известная табличка jedec говорит, что чем выше рабочая температура nand, тем лучше хранятся записанные данные.

контроллеры nvme без радиатора могут греться, да, не спорю, но ни разу не видел накопителя с контроллерами с обеих сторон )

Греется-греется! До 80 градусов доходит. А там микросхемы без ножек - припаяны на шарики бессвинцового припоя. В серверах они включены постоянно и температурный режим более-менее стабилен, в бытовых включил - выключил. Сколько-то тепловых циклов, и все: шарик припоя неконтачит, а люди думают - чип подломался. От такой неисправности никакие метрики не спасут.

Sign up to leave a comment.