Comments 40
… Резко возрастает вероятность того, что что-то пойдёт не так. Например, будут повреждены данные в пользовательском буфере чтения или записи.
Вот по-этому и нужно постоянно проверять smart. Чтобы устройство сдохло и было забраковано до того, как насосётся juicy data.
Принцип "не трогайте, оно хрупкое, а от него всё зависит" — это очень плохой принцип. Правильный принцип — долбайте изо всех сил, и если вы его не сумели сломать, то и залётного дятла оно тоже не заметит.
Further reading: chaos monkey, storm, mangle, chaos engineering.
Проблема в том, что может сдохнуть не устройство, а данные. Причём данные ценные, а сдохнуть потихоньку. У меня как-то была история, когда при записи определённой последовательности байтов на диск один битик в этой последовательности записывался неверно. Обнаружил только потому, что из паранойи переносил данные с одного диска на другой не одной операцией, как все люди делают, а сначала скопировал, потом сравнил, потом исходные удалил (бы, если бы сравнение не выявило пару отличающихся файлов). Вылечилось заменой SATA кабеля. Но чуть не рехнулся, наблюдая это всё…
Обычный факап фирмвари. В серьёзных системах это не особая проблема, потому что система хранения данных считает crc и делает deep scrub периодически. Умершие данные будут просто помечены плохими и перезалиты. Если это будет происходить постоянно, то osd помрёт (что в этой ситуации, скорее, плюс). А predictive smart это дело запомнит и начнёт на такие устройства коситься. 10-20 устройств — и оно будет "красным" ещё до форматирования.
Ну, таких «серьёзных систем» относительно мало. В моём случае проблема была на вполне домашнем сервере. Полагаю, драйвер FreeBSD игнорировал прилетающие из-за плохого проводка SATA ошибки, хотя в протоколе SATA, кажется, какая-то контрольная сумма передаётся. Что обидно, под виндой на том же самом компе всё работало нормально, наверное, виндовый драйвер контрольную сумму проверял и повторял при необходимости.
В домашних условиях (читай, на одиноком линуксе), у нас есть (для не-SAS устройств, т.к. на SAS сектора по 520 байт как раз для CRC):
1) файловые системы с чексуммами (ZoL, BTRFS).
2) блочный стек с чексуммами внутри dm-integrity.
Их достаточно, чтобы обнаружить bit rot.
Если фря игнорит dma errors, то на помойку такие драйвера.
Более того, для тривиального коррапта данных по факту записи (не bit rot), то можно поиграться с опцией -R у hdparm (write-read-verify).
Вот по-этому и нужно постоянно проверять smart. Чтобы устройство сдохло
Дохнут с идеальным СМАРТом только так. Только резервирование.
Правильный принцип — долбайте изо всех сил,
Вы так всё вселенную разнесёте :) Если серьёзно, то вам тогда либо энтерпрайз только покупать нужно (и всё равно его тестировать), либо просеивать все выпускаемые лоу-энд диски, в поисках наиболее надёжных. Владельцы крупнейших хранилищ данных примерно так и поступают. На входе фильтруют все поступающие к ним жесткие диски, специально организовывают подобные процессы, отдельные люди за этим следят. Но это далеко не всегда рентабельно.
Лучше, если диск сдохнет за гарантийный период — можно будет требовать замену/деньги. Требование к резервированию это, разумеется, не отменяет.
Ну, минимальное нагрузочное тестирование при принятии железа в продакшен — это прямо 102 системного администрирования. Когда мне аптаймы серверов ещё были не пофигу, я так всегда делал. Новый сервер минимум сутки стоял на мемтесте и ещё всеми возможными бенчмарками вжигался насколько можно. Пару раз за карьеру фигню ловило — либо память битая, либо система охлаждения криво приклеена.
Самое главное то и не написано:
наличие такой строчки вовсе не говорит о том, что диск в порядке и не выйдет из строя в ближайшее время (это время может быть и меньше суток)
SMART overall-health self-assessment test result: PASSEDналичие такой строчки вовсе не говорит о том, что диск в порядке и не выйдет из строя в ближайшее время (это время может быть и меньше суток)
Счёл, что информации о том, что диск может неожиданно сдохнуть с идеальными показателями СМАРТ, в сети и так достаточно. И в общем-то упомянул, написав:
Но наверное вы правы, стоило на это обратить внимание отдельно.
Всё равно такие проверки панацеей от неожиданного выхода диска из строя не являются
Но наверное вы правы, стоило на это обратить внимание отдельно.
Раз в сутки — считаю вполне достаточным.
О, ещё один повод у меня поныть на Хабре про недавно сдохший жёсткий диск) Регулярно посматривал SMART вручную. За день до смерти SMART был идеальный, в пятницу днём нарисовались 48 нестабильных секторов, к вечеру образовались полторы тысячи переназначенных секторов, а ещё ближе к ночи диск окончательно перестал определяться системой. Сдох меньше чем за полдня, такие вот дела
Вероятнее всего, ваш случай как раз из тех, когда диск начал сыпаться, но через СМАРТ об этом не сообщал до тех пор пока не оказался при смерти.
Я однажды просто перезагрузил сервер, после перезагрузки один диск вылетел из рейда. Диск вообще перестал опознаваться, после разобрал его, а там запилена поверхность.
\_(ツ)_/¯
\_(ツ)_/¯
«Но он же новый, свеже купленный!» — обычный аргумент.
«Люди не все умирают в старости. Утром бегал и улыбался, а вечером все что он знал и хотел сделать уже кануло в пустоту» — обычный ответ.
«Люди не все умирают в старости. Утром бегал и улыбался, а вечером все что он знал и хотел сделать уже кануло в пустоту» — обычный ответ.
Была уже стать на хабре о том что СМАРТ срабатывает лишь в половине случаев. Лично сталкивался с тем что даже мониторинг не дает 100% гарантии и диск может выйти из строя по неизвестным причинам. Поэтому соответствующий вопрос: если отбросить экзотику из разряда «кто-то толкнул шкаф и диск сломался» какие причины могут в выходе из строя накопителя?
У меня на работе два самсунга 850 про на 2тб лежат. Они в блейде были в раиде 1 и в один момент он упал полностью. Всё благополучно(из критического один exchange только был, и это уже в конце рабочего дня случилось, ) решилось хотя и весь вечер пришлось копировать виртуалки (диски были забиты на 80%), при этом смарт у них идеальный, но если оставить диски на пару, тройку дней в сервере диски вылетают оба сразу. (проверял на некритичном мегаплане и бэкап свежий был ).
Вот теперь и не знаю что с ними делать, выкидывать жалко всё таки 2тб ссд, на работе использовать нельзя. А дома пока не придумал что с ними делать, учитывая их поведение. Продажу не рассматривал по этических причинам.
Вот теперь и не знаю что с ними делать, выкидывать жалко всё таки 2тб ссд, на работе использовать нельзя. А дома пока не придумал что с ними делать, учитывая их поведение. Продажу не рассматривал по этических причинам.
Ни разу не спец, но возможно имеет место проблема в плате на них. Отвал какого-либо чипа при нагреве (может памяти, может контроллера). В этом случае smart может быть хорошим, т.к. управляющее ПО просто падает, без возможности что-либо запомнить о своем плачевном состоянии.
Отваливаться могли по разным причинам, вполне могут быть исправны. Самсунги того поколения, если я не ошибаюсь, одни из наиболее надёжных современных дисков. Напишете точное название модели, возможно скажу более определённо. SMART заскриншотьте, либо Diag dump R.tester'а покажите — можно будет понять ещё больше.
А вообще, отличный вариант для офлайновых резервных копий. Храните их на полочке и снимайте поочерёдно копии важных данных то на один, то на другой, чередуя диски.
А вообще, отличный вариант для офлайновых резервных копий. Храните их на полочке и снимайте поочерёдно копии важных данных то на один, то на другой, чередуя диски.
А что происходит с дисками, когда они живут в сервере раздельно, а не в одном логическом массиве? Если есть какие-то задачи, в которых нужен кеш и не критична его сохранность — можно переводить туда. Кеш для билд-сервера, например. Там падение не критично будет — просто запустить сборку заново.
Естественный износ, производственные дефекты, нарушения условий эксплуатации, ошибки в конструкции и прошивке, всё это вместе в разных пропорциях. Прошу извинить, я не знаю как кратко и содержательно ответить на этот вопрос.
UFO just landed and posted this here
Для того, чтобы это было возможно, либо должен существовать API от производителя и он должен поддерживаться конкретной программой, либо драйвер чипсета должен поддерживать SAT или ATA passthrough.
Попробуйте посмотреть с помощью R.tester. Если не покажет, дайте точное название чипсета в его своей материнке или её модель, и точную версию драйвера, либо ссылку на страницу сайта производителя, где лежат этот драйвер и родная утилита. Я перешлю эти данные разработчику утилиты и он добавит поддержку, если только это вообще возможно.
Попробуйте посмотреть с помощью R.tester. Если не покажет, дайте точное название чипсета в его своей материнке или её модель, и точную версию драйвера, либо ссылку на страницу сайта производителя, где лежат этот драйвер и родная утилита. Я перешлю эти данные разработчику утилиты и он добавит поддержку, если только это вообще возможно.
Да, SMART он такой СМАРТ! У меня на одном из рабочих компов уже лет пять при каждом включении он твердит, что винт сдохнет буквально сей момент. Ждем-с…
Если интересно выяснить почему так, снимите диагностический дамп R.tester'ом. Выложите куда-нибудь и дайте ссылку. Посмотрим на основе чего такие выводы делаются.
Дамп можно снять либо кнопкой «Diag dump» в главном окне, либо «Save dump» в окне с результатом «Quick DIAG».
Дамп можно снять либо кнопкой «Diag dump» в главном окне, либо «Save dump» в окне с результатом «Quick DIAG».
Я в конторе буду дней через неделю. Если не забуду к тому времени об этой переписке — сделаю. А так-то он меня особо не тревожит, там нет критических данных и работы в реал-тайм. Можно не спеша будет его поменять :)
Извиняюсь может знаете в чем можут быть проблема, когда диск цел но скорость на всей поверхности диска 10мб?
Вот сильно помогла бы таблица с расшифровкой какими попугаями измерять значения Raw для разных дисков и производителей. Ибо попугаи на много порядков разные. Для некоторых дисков миллионы Reallocated — ничто, а для других, пара тысяч — труп. И логика не просматривается. Потому мне непонятно, как вы рекомендуете на Raw опираться. Среди десятка одинаковых дисков ещё можно сравнительным анализом, а среди разных? Особенно если они не живут у вас под надзором, а приезжают на диагностику, поделитесь алгоритмом?
Raw значения попугаями измерять не надо. Это абсолютные значения. Просто смотрите их в утилите, способной отображать эти цифры в десятеричном виде и интерпретируйте. В R.tester это столбец «Value» в таблице отображения атрибутов SMART. Попугаи используются для перевода raw значения в приведённое, выводимое стандартно в качестве значения атрибута большинством утилит. Но зачем вам знать принцип этого отображения? Ориентируйтесь на raw, так будет вернее.
Какого-то общего принципа интерпретации raw значений нет. Всё очень сильно моделезависимо. Как я писал, прошивка может не отражать реалокейты в СМАРТе, а у другого диска, при том же их количестве, будет показывать. Поэтому прямо опираться на SMART, если вам нужно оценивать состояние диска не очень хороший подход. Желательно, как минимум, SMART + тесты чтения-записи. В R.tester есть алгоритм быстрой диагностики состояния диска, там как раз используется SMART + тесты в совокупности. Но там только тесты чтения.
Специалисты для оценки состояний дисков используют тесты + данные, получаемые через технопротокол, в SMART даже не заглядывают.
Какого-то общего принципа интерпретации raw значений нет. Всё очень сильно моделезависимо. Как я писал, прошивка может не отражать реалокейты в СМАРТе, а у другого диска, при том же их количестве, будет показывать. Поэтому прямо опираться на SMART, если вам нужно оценивать состояние диска не очень хороший подход. Желательно, как минимум, SMART + тесты чтения-записи. В R.tester есть алгоритм быстрой диагностики состояния диска, там как раз используется SMART + тесты в совокупности. Но там только тесты чтения.
Специалисты для оценки состояний дисков используют тесты + данные, получаемые через технопротокол, в SMART даже не заглядывают.
А не подскажите, почему программы странно иногда переводят hex в десятичные числа? Например из Crystal Disc Info:
Для Power-On Hours имеем B13, т.е. 2835 часов, но программа рисует какие-то 97 с колонке текущих… И так не только с этой прогораммой, со многими другими тоже.
ID Cur Wor Thr RawValues(6) Attribute Name
01 200 200 _51 000000000000 Read Error Rate
03 129 127 _21 00000000119C Spin-Up Time
04 _98 _98 __0 00000000082B Start/Stop Count
05 200 200 140 000000000000 Reallocated Sectors Count
07 200 200 __0 000000000000 Seek Error Rate
09 _97 _97 __0 000000000B13 Power-On HoursДля Power-On Hours имеем B13, т.е. 2835 часов, но программа рисует какие-то 97 с колонке текущих… И так не только с этой прогораммой, со многими другими тоже.
А не подскажите, почему программы странно иногда переводят hex в десятичные числа? Например из
это не программы «переводят», а столбцы Cur Wor Thr содержат некие значения формируемые микропрограммой накопителя, которые обычно ничего не имеют общего с реальным счетчиком в RawValues. Это лишь некие значения, которые формируются по известному авторам конкретной фирмвари алгоритмам, которые при достижении в Cur значения Thr позволят вари посчитать, что SMART status BAD.
В свое время пробовал немного описать о том, как происходит взаимодействие ПК с накопителем и что накопитель может отдать в SMART Важный момент, что в старой заметке не указал интервал мониторинга, который не стоит делать каждую минуту.
Присоединюсь с похожим вопросом про Power On Hours.
Раньше пользовался SATA SSD Интел и Самсунг, и там это значение нормально показывалось, похоже на правду.
Год назад начал использовать NVME Самсунг и за год почти непрерывной работы, счётчик насчитал всего лишь:
Power On Hours: 1 022
Линуксовые утилиты smartctl и nvme показывают одно и то же.
Не понятно, то ли просто криво считается или накопитель часть времени находится как-то в спячке и это время не идёт в зачёт, там есть ещё счётчик:
Controller Busy Time: 281
Раньше пользовался SATA SSD Интел и Самсунг, и там это значение нормально показывалось, похоже на правду.
Год назад начал использовать NVME Самсунг и за год почти непрерывной работы, счётчик насчитал всего лишь:
Power On Hours: 1 022
Линуксовые утилиты smartctl и nvme показывают одно и то же.
Не понятно, то ли просто криво считается или накопитель часть времени находится как-то в спячке и это время не идёт в зачёт, там есть ещё счётчик:
Controller Busy Time: 281
Потому что это не прямой перевод. Интерпретация raw значений вендоро-зависима. Надо знать как переводить. Посмотрите в R.tester.
Sign up to leave a comment.
Немного о SMART и утилитах для мониторинга