В сети достаточно много информации о SMART и значениях атрибутов. Но мне не встречались упоминания о нескольких важных моментах, про которые знаю от людей, занимающихся исследованием носителей информации.
Когда я в очередной раз рассказывал знакомому о том, почему показаниям SMART не следует безоговорочно верить и почему лучше не использовать классические «мониторилки СМАРТа» постоянно, пришла в голову идея записать сказанные слова в виде набора тезисов с пояснениями. Чтобы давать ссылки, вместо того, чтобы каждый раз пересказывать. И для ознакомления широкой аудитории.
1) Программами для автоматического мониторинга атрибутов SMART следует пользоваться с большой осторожностью.
То, что вы знаете как атрибуты SMART, не хранится в готовом виде, а генерируется в тот момент, когда вы их запрашиваете. Вычисляются они на основе внутренней статистики, накапливаемой и используемой микропрограммой накопителя в процессе работы.
Часть этих данных устройству для обеспечения основного функционала не нужна. И она не хранится, а формируется каждый раз, когда требуется. Поэтому, когда происходит запрос атрибутов SMART, микропрограмма запускает большое количество процессов, которые нужны для получения недостающих данных.
Но эти процессы плохо совместимы с процедурами, выполняемыми при нагрузке накопителя операциями чтения-записи.
В идеальном мире, это не должно было бы приводить к каким-либо проблемам. Но в реальности, прошивки жестких дисков пишут обычные люди. Которые могут ошибаться и ошибаются. Поэтому, если вы запрашиваете атрибуты SMART во время активного выполнения устройством операций чтения-записи, то резко возрастает вероятность того, что что-то пойдёт не так. Например, будут повреждены данные в пользовательском буфере чтения или записи.
Утверждение о возрастании рисков — это не теоретическое умозаключение, а практическое наблюдение. К примеру, известен баг, который имел место в прошивке HDD Samsung 103UI, где в процессе выполнения запроса атрибутов SMART, повреждались пользовательские данные.
Поэтому, не настраивайте автоматическую проверку атрибутов SMART. Если только точно не знаете, что перед этим подаётся команда сброса кэша (Flush Cache). Или, если без этого не обойтись, настраивайте выполнение проверки максимально редко. Во многих программах мониторинга, настроенное по умолчанию время между проверками — порядка 10 минут. Это слишком часто. Всё равно такие проверки панацеей от неожиданного выхода диска из строя не являются (панацея — только резервирование). Раз в сутки — считаю вполне достаточным.
Запрос температуры к запуску процессов вычисления атрибутов не приводит и может выполняться часто. Поскольку при правильной реализации это выполняется через протокол SCT. Через SCT отдаётся только то, что уже известно. Эти данные обновляются автоматически в фоновом режиме.
2) Данные атрибутов SMART зачастую недостоверны.
Микропрограмма жесткого диска показывает вам то, что считает нужным показать, а не то, что в действительности происходит. Наиболее наглядный пример, это 5й атрибут, количество переназначенных секторов. Специалистам по восстановлению данных хорошо известно, что жесткий диск может в пятом атрибуте показывать нулевое количество реалокейтов, при том, что они есть и продолжают появляться.
Я задал вопрос специалисту, изучающему жесткие диски и исследующему их микропрограммы. Поинтересовался, каков принцип, по которому прошивка устройства решает, что вот сейчас надо скрывать факт переназначения секторов, а сейчас можно рассказывать об этом через атрибуты SMART.
Он ответил, что общего правила, согласно которому устройства показывают или скрывают реальную картину не существует. И логика программистов, которые пишут прошивки жестких дисков, временами выглядит очень странно. Изучая прошивки разных моделей он увидел, что зачастую решение «скрыть или показать» принимается на основе набора параметров, которые вообще непонятно как связаны между собой и с остаточным ресурсом жесткого диска.
3) Интерпретация показателей SMART вендор-специфична.
Например, на Сигейтах не стоит обращать внимание на «плохие» raw значения атрибутов 1 и 7, пока остальные в норме. На дисках этого производителя, их абсолютные значения могут увеличиваться в процессе нормальной эксплуатации.
Для оценки состояния и остаточного ресурса жесткого диска, в первую очередь рекомендуется обращать внимание на параметры 5, 196, 197, 198. Причём, ориентироваться имеет смысл именно на абсолютные, сырые значения (raw), а не на приведённые. Приведение атрибутов может выполняться неочевидными способами, различными в разных алгоритмах и прошивках.
Вообще, в среде специалистов по носителям информации, когда говорят про значение атрибута, обычно подразумевается именно абсолютное значение.
Когда я в очередной раз рассказывал знакомому о том, почему показаниям SMART не следует безоговорочно верить и почему лучше не использовать классические «мониторилки СМАРТа» постоянно, пришла в голову идея записать сказанные слова в виде набора тезисов с пояснениями. Чтобы давать ссылки, вместо того, чтобы каждый раз пересказывать. И для ознакомления широкой аудитории.
1) Программами для автоматического мониторинга атрибутов SMART следует пользоваться с большой осторожностью.
То, что вы знаете как атрибуты SMART, не хранится в готовом виде, а генерируется в тот момент, когда вы их запрашиваете. Вычисляются они на основе внутренней статистики, накапливаемой и используемой микропрограммой накопителя в процессе работы.
Часть этих данных устройству для обеспечения основного функционала не нужна. И она не хранится, а формируется каждый раз, когда требуется. Поэтому, когда происходит запрос атрибутов SMART, микропрограмма запускает большое количество процессов, которые нужны для получения недостающих данных.
Но эти процессы плохо совместимы с процедурами, выполняемыми при нагрузке накопителя операциями чтения-записи.
В идеальном мире, это не должно было бы приводить к каким-либо проблемам. Но в реальности, прошивки жестких дисков пишут обычные люди. Которые могут ошибаться и ошибаются. Поэтому, если вы запрашиваете атрибуты SMART во время активного выполнения устройством операций чтения-записи, то резко возрастает вероятность того, что что-то пойдёт не так. Например, будут повреждены данные в пользовательском буфере чтения или записи.
Утверждение о возрастании рисков — это не теоретическое умозаключение, а практическое наблюдение. К примеру, известен баг, который имел место в прошивке HDD Samsung 103UI, где в процессе выполнения запроса атрибутов SMART, повреждались пользовательские данные.
Поэтому, не настраивайте автоматическую проверку атрибутов SMART. Если только точно не знаете, что перед этим подаётся команда сброса кэша (Flush Cache). Или, если без этого не обойтись, настраивайте выполнение проверки максимально редко. Во многих программах мониторинга, настроенное по умолчанию время между проверками — порядка 10 минут. Это слишком часто. Всё равно такие проверки панацеей от неожиданного выхода диска из строя не являются (панацея — только резервирование). Раз в сутки — считаю вполне достаточным.
Запрос температуры к запуску процессов вычисления атрибутов не приводит и может выполняться часто. Поскольку при правильной реализации это выполняется через протокол SCT. Через SCT отдаётся только то, что уже известно. Эти данные обновляются автоматически в фоновом режиме.
2) Данные атрибутов SMART зачастую недостоверны.
Микропрограмма жесткого диска показывает вам то, что считает нужным показать, а не то, что в действительности происходит. Наиболее наглядный пример, это 5й атрибут, количество переназначенных секторов. Специалистам по восстановлению данных хорошо известно, что жесткий диск может в пятом атрибуте показывать нулевое количество реалокейтов, при том, что они есть и продолжают появляться.
Я задал вопрос специалисту, изучающему жесткие диски и исследующему их микропрограммы. Поинтересовался, каков принцип, по которому прошивка устройства решает, что вот сейчас надо скрывать факт переназначения секторов, а сейчас можно рассказывать об этом через атрибуты SMART.
Он ответил, что общего правила, согласно которому устройства показывают или скрывают реальную картину не существует. И логика программистов, которые пишут прошивки жестких дисков, временами выглядит очень странно. Изучая прошивки разных моделей он увидел, что зачастую решение «скрыть или показать» принимается на основе набора параметров, которые вообще непонятно как связаны между собой и с остаточным ресурсом жесткого диска.
3) Интерпретация показателей SMART вендор-специфична.
Например, на Сигейтах не стоит обращать внимание на «плохие» raw значения атрибутов 1 и 7, пока остальные в норме. На дисках этого производителя, их абсолютные значения могут увеличиваться в процессе нормальной эксплуатации.
Для оценки состояния и остаточного ресурса жесткого диска, в первую очередь рекомендуется обращать внимание на параметры 5, 196, 197, 198. Причём, ориентироваться имеет смысл именно на абсолютные, сырые значения (raw), а не на приведённые. Приведение атрибутов может выполняться неочевидными способами, различными в разных алгоритмах и прошивках.
Вообще, в среде специалистов по носителям информации, когда говорят про значение атрибута, обычно подразумевается именно абсолютное значение.
amarao
Вот по-этому и нужно постоянно проверять smart. Чтобы устройство сдохло и было забраковано до того, как насосётся juicy data.
Принцип "не трогайте, оно хрупкое, а от него всё зависит" — это очень плохой принцип. Правильный принцип — долбайте изо всех сил, и если вы его не сумели сломать, то и залётного дятла оно тоже не заметит.
Further reading: chaos monkey, storm, mangle, chaos engineering.
zzzzzzzzzzzz
Проблема в том, что может сдохнуть не устройство, а данные. Причём данные ценные, а сдохнуть потихоньку. У меня как-то была история, когда при записи определённой последовательности байтов на диск один битик в этой последовательности записывался неверно. Обнаружил только потому, что из паранойи переносил данные с одного диска на другой не одной операцией, как все люди делают, а сначала скопировал, потом сравнил, потом исходные удалил (бы, если бы сравнение не выявило пару отличающихся файлов). Вылечилось заменой SATA кабеля. Но чуть не рехнулся, наблюдая это всё…
amarao
Обычный факап фирмвари. В серьёзных системах это не особая проблема, потому что система хранения данных считает crc и делает deep scrub периодически. Умершие данные будут просто помечены плохими и перезалиты. Если это будет происходить постоянно, то osd помрёт (что в этой ситуации, скорее, плюс). А predictive smart это дело запомнит и начнёт на такие устройства коситься. 10-20 устройств — и оно будет "красным" ещё до форматирования.
zzzzzzzzzzzz
Ну, таких «серьёзных систем» относительно мало. В моём случае проблема была на вполне домашнем сервере. Полагаю, драйвер FreeBSD игнорировал прилетающие из-за плохого проводка SATA ошибки, хотя в протоколе SATA, кажется, какая-то контрольная сумма передаётся. Что обидно, под виндой на том же самом компе всё работало нормально, наверное, виндовый драйвер контрольную сумму проверял и повторял при необходимости.
amarao
В домашних условиях (читай, на одиноком линуксе), у нас есть (для не-SAS устройств, т.к. на SAS сектора по 520 байт как раз для CRC):
1) файловые системы с чексуммами (ZoL, BTRFS).
2) блочный стек с чексуммами внутри dm-integrity.
Их достаточно, чтобы обнаружить bit rot.
Если фря игнорит dma errors, то на помойку такие драйвера.
Более того, для тривиального коррапта данных по факту записи (не bit rot), то можно поиграться с опцией
-Rу hdparm (write-read-verify).lll000lll Автор
Дохнут с идеальным СМАРТом только так. Только резервирование.
Вы так всё вселенную разнесёте :) Если серьёзно, то вам тогда либо энтерпрайз только покупать нужно (и всё равно его тестировать), либо просеивать все выпускаемые лоу-энд диски, в поисках наиболее надёжных. Владельцы крупнейших хранилищ данных примерно так и поступают. На входе фильтруют все поступающие к ним жесткие диски, специально организовывают подобные процессы, отдельные люди за этим следят. Но это далеко не всегда рентабельно.
DaemonGloom
Лучше, если диск сдохнет за гарантийный период — можно будет требовать замену/деньги. Требование к резервированию это, разумеется, не отменяет.
amarao
Ну, минимальное нагрузочное тестирование при принятии железа в продакшен — это прямо 102 системного администрирования. Когда мне аптаймы серверов ещё были не пофигу, я так всегда делал. Новый сервер минимум сутки стоял на мемтесте и ещё всеми возможными бенчмарками вжигался насколько можно. Пару раз за карьеру фигню ловило — либо память битая, либо система охлаждения криво приклеена.