бивисописцы обычно проверяют только smart health status и это имеет смысл. Другой вопрос, что часть из них если smart health fail выводят на экран сообщение и ждут нажатия кнопки, вот за это точно надо руки отрывать.

Что касается атрибутов - обычно никто ничего особо не прячет. Там 2 основных проблемы:

1) это отсутствие стандартизации атрибутов и у кучи вендоров внятного описания их. Обычно с enterprise железками немного лучше, там можно в недрах сайта найти мануал с описаниями, у дешевых ендюзерский, особенно OEM, вообще никто не заморачивается. У scsi/sas очень модно сделать свою log page с уникальным форматом, который никто читать не умеет, включая вендорские утилиты ))

2) немного улучшил ситуацию -l devstat лог, в котором атрибуты и их значения стандартизированы, но им мало кто пользуется, увы. А там где он есть - далеко не всегда все поля заполнены, причем я склонен тут винить обычное разгильдяйство, а не злой умысел.

3) есть и куча глюков в самих firmware дисков, так что написанному не всегда удается верить.

4) У ssd, кстати, достаточно часто бывает внутренний атрибут с количеством сбойных ячеек после производства, это нормально, опять же - никто ничего не скрывает, но описание приходится долго искать, чаще, кстати, в случае ssd легче найти спеку на контроллер чем описание от вендора, благо большинство вендоров референсный фирмвар почти не трогают. Отдельные китайцы, кстати, настолько, сцуко, ленивы, что вообще не трогают и оставляют в model "SATA DISK" и такое можно идентифицировать только по номеру firmware (реальные кейзы)