Если SSD умирают через 40 000 часов, то все бэкапы могут сгореть одновременно +53



На железячных форумах периодически поднимается тема про «40 000 часов». Речь о том, что из-за бага в прошивке некоторые накопители выходят из строя через 40 000 часов работы (четыре года, 206 дней, 16 ч).

Это не городская легенда, а реально известный баг у некоторых SSD производства SanDisk, которые повсеместно используются в индустрии, в том числе в серверах, NAS и других сетевых продуктах разных фирм.

С точки зрения сисадмина, выход из строя одного накопителя через четыре года — не такое критическое событие, если у нас резервные копии на нескольких SSD. Хотя постойте…

Вообще, об этой проблеме известно как минимум с 2019 года. Однако в то время мало кто обратил внимание на эту информацию…

Баги в прошивках


В 2020 году компания Hewlett-Packard рекомендовала обновить прошивки четырёх фирменных SSD:

  • HPE 800GB 12G SAS WI-1 SFF SC SSD (номер детали 846622-001)
  • HPE 800GB 12G SAS MU-1 SFF SC SSD (846624-001)
  • HPE 1.6TB 12G SAS WI-1 SFF SC SSD (846623-001)
  • HPE 1.6TB 12G SAS MU-1 SFF SC SSD (846625-001)

Эти накопители поставляются с множеством сетевых продуктов HPE, включая HPE ProLiant, Synergy, Apollo 4200, Synergy Storage Modules, D3000 Storage Enclosure, StoreEasy 1000 Storage.

К сожалению, прошивка проприетарная, код не публикуется в открытом доступе, как и патчи для него. В описании патча от Dell написано, что он исправляет «ошибку проверки максимального значения индекса циркулярного буфера» (судя по всему, максимально допустимое значение уменьшалось на единицу при каждой проверке). То же самое написано в исправлении прошивки Lightning Gen II SAS:



Годом ранее Hewlett-Packard сообщала о похожем баге, когда SSD тоже выходил из строя через определённое количество часов, а именно 32 768.

32 768 часов


В ноябре 2019 года речь шла о двадцати моделях SSD, которые поставляются с серверами и хранилищами HPE ProLiant, Synergy, Apollo, JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4335 и StoreVirtual 3200:

Список SSD, подверженных «внезапной смерти»:

  • HP 480GB 12Gb SAS 2.5 RI PLP SC SSD (номер детали 817047-001)
  • HP 960GB 12Gb SAS 2.5 RI PLP SC SSD (817049-001)
  • HP 1.92TB 12Gb SAS 2.5 RI PLP SC SSD (817051-001)
  • HP 3.84TB 12Gb SAS 2.5 RI PLP SC SSD (817053-001)
  • HP 400GB 12Gb SAS 2.5 MU PLP SC SSD S2 (822784-001)
  • HP 800GB 12Gb SAS 2.5 MU PLP SC SSD S2 (822786-001)
  • HP 1.6TB 12Gb SAS 2.5 MU PLP SC SSD S2 (822788-001)
  • HP 3.2TB 12Gb SAS 2.5 MU PLP SC SSD S2 (822790-001)
  • HPE 480GB SAS SFF RI SC DS SSD (875681-001)
  • HPE 960GB SAS SFF RI SC DS SSD (875682-001)
  • HPE1.92TB SAS RI SFF SC DS SSD (875684-001)
  • HPE 3.84TB SAS RI SFF SC DS SSD (875686-001)
  • HPE 7.68TB SAS 12G RI SFF SC DS SSD (870460-001)
  • HPE 15.3TB SAS 12G RI SFF SC DS SSD (870462-001)
  • HPE 960GB SAS RI SFF SC DS SSD (P08608-001)
  • HPE 1.92TB SAS RI SFF SC DS SSD (P08609-001)
  • HPE 3.84TB SAS RI SFF SC DS SSD (P08610-001)
  • HPE 3.84TB SAS RI LFF SCC DS SPL SSD (P11360-001)
  • HPE 7.68TB SAS RI SFF SC DS SSD (P08611-001)
  • HPE 15.3TB SAS RI SFF SC DS SSD (P08612-001)

В официальном руководстве компания Hewlett-Packard рекомендует владельцам потенциально уязвимых SSD проверить параметр Power-on Hours в программе мониторинга Smart Storage Administrator.



В случае необходимости патч устанавливается специальным инструментом для прошивки HDD/SSD под VMware ESXi, Windows и Linux.

«После выхода из строя SSD ни сам накопитель, ни данные восстановить невозможно. Кроме того, SSD, которые введены в эксплуатацию в одно и то же время, скорее всего, выйдут из строя почти одновременно», — сказано в сообщении HP.

Основным виновником сбоя HP назвала «стороннего подрядчика, который занимался разработкой и производством SSD для компании». Конкретное имя подрядчика не прозвучало, но шила в мешке не утаишь. Вскоре выяснилось, что это были накопители SanDisk (подразделение Western Digital).

SanDisk — один из крупнейших в мире производителей SSD, а львиную долю накопителей он производит по заказу крупных вендоров, так что они продаются не под маркой SanDisk, а под маркой HPE, Cisco и др.

В феврале 2020 года об аналогичном баге предупредила компания Dell:



Как можно понять, затронуты различные модели SSD SanDisk ёмкостью от 200 ГБ до 1,6 ТБ. Теоретически, «внезапная смерть» может затронуть устройства разных вендоров под другими брендами. Некоторые из них не признались публично, что использовали эти SSD. Они надеются на авось, что немногие пострадавшие спишут сбой на «естественные причины».

Падение Hacker News


Таким образом, в мире продолжают работать десятки тысяч непропатченных SSD, которые с каждой минутой приближаются к роковому времени. Новости о багах прошивок в 2019 и 2020 годах прошли, по сути, незамеченными. Мол, это какие-то корпоративные продукты… Никто не думал, что проблема затронет лично его. Но вот наступил «час Х».

8 июля 2022 года упал популярный сайт Hacker News. Разработчики по всему миру целый день маялись без привычного чтива, ведь в западном IT-сообществе это чуть ли не главный сайт для новостей и общения, примерно как Хабр в русскоязычном сегменте.

Когда упал основной сервер HN, нагрузку перевели на резервный — но он тоже упал.


Естественно, возникает вопрос, как у главного IT-сайта в мире могут возникнуть такие проблемы с бэкапами? А вот так. Как потом выяснилось, основные и резервные серверы работали на накопителях SanDisk Optimus Lightning II и отработали примерно одинаковый срок. Cкладывается впечатление, сисадмины HN вообще не могли представить, что все накопители могут выйти из строя в одну минуту:



На обоих серверах работала установка RAID, то есть как минимум четыре SSD вышли из строя почти одновременно.

Это нормальная ситуация, когда несколько серверов запускается в один день. На каждом стоит массив RAID из двух или более накопителей. Казалось бы, это гарантирует почти абсолютную защиту от фатальных сбоев и аптайм 99,999%. По теории вероятности, ну как могут четыре накопителя в двух RAID выйти из строя одновременно? А вот бывает.

К счастью, у Hacker News нашлись резервные копии на других серверах (с другими накопителями), так что работа сайта была восстановлена через 14 часов после падения первого сервера (и через 8 часов после второго).

И это не единственный случай, когда несколько HDD/SSD выходят из строя в один момент.

Чёрные лебеди


«Чёрный лебедь» — явление очень редкое, но с катастрофическими последствиями. Однако на бесконечно длинном промежутке времени вероятность даже самого редкого события стремится к 1. То есть прилёт «чёрного лебедя» можно гарантировать на 100%. Вопрос только в том, когда это случится.

И вопрос в том, насколько адекватно мы оцениваем риски, то есть насколько реалистично оцениваем вероятность того или иного события. История с четырьмя SSD показывает — то, что мы считали как четыре разных события (перемножая их вероятности), на самом деле может оказаться одним событием.

А ведь такое очень часто происходит и на работе, и в жизни. Мы строим десяток «запасных планов» на все случаи. А потом оказывается, что все «запасные стратегии» накрылись из-за одного-единственного события. И на самом деле это вовсе не «запасные стратегии», а скорее иллюзия безопасности, самообман.



Из этой истории напрашивается вывод. Если опасности не видно, то последствия сбоя могут оказаться хуже, чем если мы заранее предусмотрели множество рисков и продумали сценарии ответных действий.

Получается, что чем больше рисков мы видим перед собой — тем лучше. И наоборот, самая опасная ситуация — когда всё вокруг хорошо и спокойно. Это реальный повод включать все сигнализации.


В ментальной модели будущего человек видит те варианты развития событий, которые способен понять в силу имеющихся знаний и информации. Воображение помогает представить, какие знания у нас отсутствуют, чтобы дополнить ментальную модель (второй шаг в технике Фейнмана). Но воображение тоже не безгранично…

Мне кажется, отсюда возникает побочное следствие — самый худший сценарий невозможно представить (потому что всегда возможен ещё более худший). И это в каком-то смысле успокаивает, потому что перфекционизм оказывается ни к чему. Достаточно сделать только то, что в наших силах, и успокоиться на этом.

Ну а практический вывод из этой истории такой, что в один RAID нежелательно ставить накопители одной модели, а тем более из одной партии (с серийными номерами подряд).




Комментарии (75):

  1. YMA
    /#24608284 / +16

    Бэкапы по правилу "3-2-1" - не помним. И держим резервные копии на SSD.

    Да уж...

    • v1000
      /#24610910

      Тем более что RAID это скорее про доступность данных, а не надежность. В свое время софтверный RAID 1 умудрился все данные испортить после ребилда, при этом сами диски были в порядке. Хотя, казалось бы, что сложного в банальном зеркалировании данных...

      • edo1h
        /#24615080

        Хотя, казалось бы, что сложного в банальном зеркалировании данных...

        очевидно, сложно определить какая из копий сектора верна, в raid1 нет соответствующей метаинформации (и если её добавить, то это ×2 к iops на запись).
        в этом плане zfs правильно устроена, там есть merkle tree, которое позволяет валидировать данные, в том числе и в случае «рассинхрона» зеркала.

    • edo1h
      /#24615076

      И держим резервные копии на SSD.

      скорее у автора статьи в голове каша, он не отличает резервные копии от raid

      • vorphalack
        /#24615082 / +1

        мы рейд покупали не для того, чтоб делать резервные копии, уволен! /s

  2. QuAzI
    /#24608374 / +2

    Любители подешевле так и не дали умереть этим бракоделам... а жаль... вот уж много лет как обхожу их стороной после жмени мёртвых флешек разных моделей

  3. usernotfound_yet
    /#24608438 / -32

    для меня как владельца HDD статейки про смерть SSD всегда повод для умиления и попкорна. Когда я предупреждал - все улыбались, теперь моя очередь улыбаться.

    и Пы.Сы. - я не страдаю от низкой скорости считывания, я просто обхожу ее стороной и пользуюсь ОЗУ (у нее еще пока циклы бесплатные, капиталисты пока до этого момента еще не добрались, но и это ненадолго, ибо "бесплатная работа еще и без подписки" не дает спокойно спать ночами всяким маркетологам и спецам по запланированному устареванию).

    • KorP
      /#24608456 / +21

      Будто в прошивках HDD не бывает багов :)))

    • TimsTims
      /#24608464 / +12

      статейки про смерть SSD всегда повод для умиления

      Вы не страдаете, но не значит, что остальным не нужны SSD. Плюс большинство статей прошлого касалось ограниченного ресурса ssd, связанного с их циклами перезаписи. А статья вообще о другом - о баге в прошивке. Точно такой-же баг мог в теории произойти и в HDD. Так-что это вообще не связанно с типом диска.

      Пы.Сы. - я не страдаю от низкой скорости считывания и пользуюсь ОЗУ.

      Вы не страдаете, а я страдаю. А как вы в ОЗУ игры храните например? Браузер долго запускается? Или вы просто не выключаете никогда никакие проги?

    • konst90
      /#24608712 / +32

      для меня как владельца HDD

      Вы видимо не слышали про WD Green, которые парковали головки через 8 секунд бездействия, что в определённых моделях использования убивало диски за два-три года.

      И таких примеров у разных производителей - море.

      • mdevaev
        /#24610996

        О да, и для отключения этой фичи они выпустили аж целую утилиту под дос, которую надо было как-то еще запустить.

        • ez2
          /#24611760

          HDDscan с GUI прямо из Win 7, hdparm для Linux. Впрочем, не помню, когда там сон появился, изначально вроде была только скорость головки(шум).

          • mdevaev
            /#24613270

            Нет, это не то же самое. Парковка головок лечилась только этой утилитой, она была в прошивку зашита и не имела параметров извне.

            • ez2
              /#24614496

              HDDscan-> круглая кнопка->features->power management->idle timer

              Работает на всех CMR WD

      • demitel
        /#24611478 / +1

        А ещё были диски Fujitsu, у которых таблица ошибок smart из-за отсутствия проверки могла вылезти за отведённые границы и шла перезапись каких-то важных заводских настроек, после чего винт умирал.

    • Inine
      /#24608828 / +2

      Помню, когда покупал в 2002 свой первый комп, то все друзья говорили мне "главное, не купи Дятла! И вообще, ну его Айбиэм этот, бери лучше Сигейт". Так что удачи верующим)

      • Didimus
        /#24609632

        Как раз после того купил Сигей с неправильно откалиброванным термодатчиком, он переставал писать во время работы. В гарантийку с таким дефектом его сдать не смог, так как там выполняли только тест чтения поверхности...

      • Dolios
        /#24610198 / +2

        Еще фуджики с циррозом примерно в то же время были..

        • vorphalack
          /#24615074

          цирроз и дятлы все же аппаратные были, причем цирроз проходил по статье «хотели как лучше, а получилось даже хуже чем обычно» :)

      • AlexanderS
        /#24610766 / +2

        А через несколько лет сигейт мухой СС отметился)

    • creker
      /#24609160 / +3

      я не страдаю от низкой скорости считывания, я просто обхожу ее стороной и пользуюсь ОЗУ

      Базу на десяток ТБ в памяти мне разместите пожалуйста

    • hyperwolf
      /#24612518 / +1

      Ну запихайте несколько десятков терабайт логов в ОЗУ. Или базу схожего размера. Дома-то порнуху можно хоть на дискетах хранить, но мир не ограничен домашними ПК.

    • Demiourgos
      /#24613390

      Запланированное устаревание? Осень интересно.

      Во-первых, насколько я понял, речь в статье идёт об ошибке.

      Во-вторых, запланированного устаревание -- это жупел сторонников теории заговора. Оглянувшись вокруг можно увидеть много вещей которые, отработали не то чтобы гарантийный срок, а больше чем запланированный срок службы. Где запланированое устаревание?

  4. KorP
    /#24608454 / +7

    Бекапы на SSD? Красиво жить не запретишь :)

    Новости о багах прошивок в 2019 и 2020 годах прошли, по сути, незамеченными.

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

    Когда упал основной сервер HN, нагрузку перевели на резервный — но он тоже упал.

    Естественно, возникает вопрос, как у главного IT-сайта в мире могут возникнуть такие проблемы с бэкапами?

    При чём тут вообще бекап?

    • TimsTims
      /#24608502

      Тут вроде речь не про бэкапы на дисках, а бэкап-сервер, который работал на таких же дисках.

      • KorP
        /#24608512

        Пока я вижу желтушный заголовок про потерю бекапов и инфу по прошивкам двухлетней давности...

        Что же касается резервного сервера - ну он резервный сервер, но не бекапы же :)

    • EvgeniyNuAfanasievich
      /#24608526 / +1

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

      • KorP
        /#24608562

        Нет, она совершенно не глупая, и есть стораджовые вендоры, у которых нет дисковых массивов, которые её активно двигают в людей :) Другой вопрос, что позволить себе такое решение могут далеко не все, ввиду своей высокой стоимости. Тут нужно исходить из стоимости простоя сервисов и тд.

  5. HepoH
    /#24608920 / +15

    На самом деле, на странице RAID в википедии есть короткий абзац, который выражает смысл этой статьи (помимо штуки с багом в прошивке):

    Коррелированные сбои

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

    • 13werwolf13
      /#24608956 / +11

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

      • ruomserg
        /#24609140 / +8

        … а еще мы предупреждаем клиентов, что диски сидят на одной шине и на одном питании, а также в одном физическом месте. И это несет риски катастрофического отказа.

        А потом мы спрашиваем клиента — какая у него в голове модель максимальной проектной аварии? А у него нету. Или он говорит, что хочет защититься от всего. А когда считаешь ему стоимость правильного резерва с географически разделенными локациями, и проч — он не хочет платить. И так и работает на как-то собранном в raid сервере…

        Второй вариант ответа — давайте возьмем сервис в облаке/датацентре, там все будет 100% надежно. Почему? А так в ролике в интернете сказали (специалисты же врать не будут ...) :-(

        • SergeyMax
          /#24609336 / +1

          давайте возьмем сервис в облаке/датацентре, там все будет 100% надежно.

          Обычно для облака указан процент доступности, и там нет указанной вами цифры.

          • ruomserg
            /#24609414 / +2

            Там сложно написано и непонятно… А в интернете на деньги маркетологов эхсперты пишут, что свой сервер — ненадежно, а облако или ЦОД — другое дело…

            • SergeyMax
              /#24609430

              Ну вообще так и есть, в среднем свой сервер + среднестатистический местный админ — это гораздо менее надёжная вещь, чем машина в облаке амазона.

              • ruomserg
                /#24609876 / +4

                Боюсь, что это очень зависит опять-таки от сценария МПА, который держит в голове клиент. Потому что теперь мы добавили канал связи, перестали управлять рисками внутри подрядчика, и отказались от экспертизы внутри компании, которая при аварии молга хоть что-то придумывать и делать. Да, экспертиза внутри компании бывает плохая и может даже сделать еще хуже чем если ничего не делать… Но теперь ее нет, и все что остается делать — это писать письма в поддержку…

                В общем, безусловно — решение отдать сервер в облако меняет ландшафт рисков, но отнюдь их не устраняет.

                И да, лучше всего работает локальный сервер с географически распределенным резервом и бэкапами (в то же облако). Но… денег же жалко, и экспертизы нет. А экспертизы нет, потому что всем жалко денег…

                • SergeyMax
                  /#24610508

                  и отказались от экспертизы внутри компании,

                  Тут вон эксперт ниже спрашивает, что будет, если один диск отключить. И хоть вы зауправляйтесь своими рисками и сценариями, в среднем по больнице оно как-то так всегда и выглядит.

      • d2d8
        /#24609934 / +2

        Всю жизнь ставил зеркала из одинаковых дисков из одной партии из соображений того, чтоб диски были одинаковой скорости и объем до байтика сходился. И даже после выхода одного из дисков из строя менял сразу пару на опять же одинаковые. И только после этой статьи и комментариев до меня дошла пагубность данной практики, ведь зеркало создается не для "работы", а для "поломки". Век живи, век учись.

        P.S. Правда пару раз попадал в небольшую неприятность когда приходилось менять один из пары на другую модель и вот там эти различия в пару байт мешали нормально восстановить md raid. Победить это не сложно или создавать изначально raid не на весь объем, но видимо тоже служило причиной использования абсолютно одинаковых дисков.

        • Loggus66
          /#24611786

          А как победить? Уменьшить ФС и RAID следом?

          • bugbringer
            /#24611806

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

            • arheops
              /#24613518

              А просто взять новый диск больше? Вообще у софт рейда на такой случай в конце пару мегабайт неиспользуемого пространства.

              • bugbringer
                /#24613852

                На тот момент была нехватка денег вплоть до того, что лучше потерять полдня, чем купить ещё один диск.

          • d2d8
            /#24617398

            Первые разы именно так и делал, по дороге вылезали какие-то проблемы, уже не вспомню какие, да и не быстро это было. Так что потом просто создавал на новой паре дисков рейд заново и копировал данные.

    • Revertis
      /#24610050 / -1

      Таааак, и тут я захотел отключить на время один диск из софтового райда (через mdadm), а потом вернуть его в райд. Такое можно нормально сделать? Чтобы нормально потом синканулся райд.

      • HepoH
        /#24610154

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

        • Revertis
          /#24610162 / -1

          Ну вот восстановление массива сложная операция вообще, если нет нагрузки на сервер?

          • HepoH
            /#24610174

            Не могу ответить, пока ни разу не доводилось выполнять. Знаю только, что в этот момент нагрузка на диски крайне высока, и это опасный момент в плане того, что если вышел из строя один диск, и вы восстанавливаете структуру массива, есть риск выхода других дисков из строя из-за интенсивной нагрузки и, собственно, корреляции выше.

            • saboteur_kiev
              /#24610950

              Почему крайне высокая?
              В нормальном рейд контроллере можно выставить в процентах допустимую нагрузку для синхронизации дисков в массиве.

              Вдобавок в рейде типа 10, выход из строя одного диска практически не влияет на производительность.

              Итого, давим 5% мощности на синхронизаци. Нагрузка вырастет на не более чем 5%.

              • HepoH
                /#24611056 / +3

                Повторюсь, не то чтобы я эксперт по рейдам, оперирую данными со всяких википедий.

                В нормальном рейд контроллере можно выставить в процентах допустимую нагрузку для синхронизации дисков в массиве

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

                Насчет крайне высокой, это я запомнил, когда про пятый рейд читал:
                При выходе из строя одного диска надёжность тома сразу снижается до уровня RAID 0 с соответствующим количеством дисков n−1, то есть в n−1 раз ниже надёжности одного диска — данное состояние называется критическим (degrade или critical). Для возвращения массива к нормальной работе требуется длительный процесс восстановления, связанный с ощутимой потерей производительности и повышенным риском. В ходе восстановления (rebuild или reconstruction) контроллер осуществляет длительное интенсивное чтение, которое может спровоцировать выход из строя ещё одного или нескольких дисков массива. Кроме того, в ходе чтения могут выявляться ранее не обнаруженные сбои чтения в массивах cold data (данных, к которым не обращаются при обычной работе массива, архивные и малоактивные данные), препятствующие восстановлению. Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается и данные на нём восстановлению обычными методами не подлежат.

                • PowerMetall
                  /#24612554 / +1

                  Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается

                  У нас в компании как раз такое и произошло несколько лет назад.
                  Данные восстановили. Правда за очень долгий срок, в далеко не полном объёме, и ОЧЕНЬ недёшево (сисадмин отправлял СХД в контору, специализирующуюся на такого рода вещах)

                  На СХД были пользовательские файлы, но самое главное - база данных MSSQL на пару терабайт. Базу, само собой, восстановить не вышло ((

                • st1373
                  /#24612900

                  я ставил тест на системе, аппаратный vs программный, ну вообщем аппаратный гораздо шустрее, точных цифр не помню, но до 5-10 раз, диски SATA-HDD. Крайний раз прислали сервер тоже уже с контроллером, но там все специфично.

                  ЗЫ может ли выйти 2 диска одновременно? запросто, поэтому я стал заводить raid6, ну кое-где и raid1, но дисков больше 2-х + желательно spare

                • saboteur_kiev
                  /#24614318

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

                  Так это относится собственно именно к пятому рейду. У него есть проблемы с перформансом, зато он гораздо дешевле, чем зеркало и может быть почти таким же быстрым, как райд1 по чтению, но с некоторой отказоустойчивостью. Ну или есть еще 6-й рейд.

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

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

          • Naves
            /#24610272 / +1

            Начнется rebuild массива, это значит, что с первого диска прочитаются ВСЕ данные, и запишутся на вставленный заново диск. mdraid понятия не имеет какие сектора с данными у вас изменились с момента отключения диска.

            Если на рабочем диске, с которого будет чтение, найдутся bad-блоки, то raid не соберется.

            В идеале вам нужен третий диск, который вставите вместо одного старого, на него и делайте rebuild.

            В крайнем случае перед "операцией" можно сделать resync массива, который возможно найдет дефекты на дисках, если они есть.

            • saboteur_kiev
              /#24610952

              Если массив большой, то с каждого диска прочитается немного данных, и сделают это не одновременно, а в продолжительный процент времени. Тем более, что порядочные контроллеры могут и так видеть нагрузку и на восстановление/синхронизацию тратить время простоя.

      • regs
        /#24610248 / +2

        Если Raid 1, то можно. Только если когда массив онлайн. Если отключить диск в офлайне, то при пуске массив не соберётся и станет поломанным Raid 0. При каждом пуске его придётся пересобирать вручную. Давняя проблема mdadm, но никого не волнует.

        ZFS же запустится, но из офлайна запасные диски в используемые не перейдут. Только если какой-то диск пропал в онлайне, то spare диск перейдёт в inuse.

        • Revertis
          /#24610268 / +1

          Понятно. Значит лучше не теребить мой raid1. Но там всё равно сервер для бэкапов, если он сдохнет, то на основной сервер это не повлияет. Только придётся бежать за новыми дисками.

          • bugbringer
            /#24611770

            Если вопрос изначально в том, чтобы разнести диски по времени использования - чтобы они не вышли из строя в один день, то я бы от себя посоветовал альтернативный вариант. Добавить третий диск - по вкусу в качестве рабочего или хотспара. Для паранойи лучше хотспар, конечно. И можно спокойно ждать выхода из строя.

        • arheops
          /#24614230

          С какого перепугу не собереться масив если диск в офлайне отключить? Собереться, просто будет диск missing/failed, в зависимости от контролера. В madam будет missed.
          Постоянно в офлайне отключаю.

  6. isden
    /#24609196 / +5

    А можно где-то посмотреть полный список SSD с этим багом?

  7. CaptainFlint
    /#24609330 / +5

    Ну а практический вывод из этой истории такой, что в один RAID нежелательно ставить накопители одной модели, а тем более из одной партии (с серийными номерами подряд).
    Сколько помню, всегда как раз рекомендовалось использовать максимально одинаковые диски, чтобы избежать дисбаланса в параметрах чтения-записи и связанных с ним потерь производительности. Да ещё и покупать в запас для будущей замены, так как когда диск сдохнет, в продаже скорее всего уже не окажется такой модели.

    Но проблема с одновременностью, конечно, имеется; вот и гадай теперь, как быть…

    • ruomserg
      /#24609884 / +1

      Да ну! Всегда просили ставить диски разных производителей — а если это невозможно, то хотя бы разных партий и разных дат поставок. Именно для того, чтобы избежать ситуации, когда вся партия имеет скрытый дефект…

      • v1000
        /#24610926

        вся партия имеет скрытый дефект…

        В свое время массово начали выходить из строя диски одной модели и одной партии. После чего появился слух, что в порту при разгрузке немного уронили контейнер с этой партией дисков.

    • eptr
      /#24611282 / +3

      Но проблема с одновременностью, конечно, имеется; вот и гадай теперь, как быть…

      Очень просто: скажем, каждые 3 месяца докупается один диск и меняется на один из тех, что был установлен в RAID'е с самого начала, и так -- пока не будет докуплено N - 1 дисков.

      В результате, в RAID'е будут диски с "разбегом" в 3 месяца, а в запасе тоже будут диски, с частично отработанным ресурсом.

      В дальнейшем, при выходе из строя дисков в RAID'е, логично будет заменять их на диски из запаса, выбирая такие из них, чтобы "разбег" по выработке ресурса дисков в RAID'е оставался относительно равномерным.

      Риск того, что новые диски в самом начале массово начнут выходить из строя, невелик.
      Да и никакие ухищрения при таком развитии событий не спасут.

      Но чем дальше от момента создания RAID'а, тем диверсифицированнее при таком подходе становится защита от флеш-моба дискового "падежа".

      За уменьшение риска в одном месте приходится платить увеличением рисков в другом, а именно, -- тем, что запасные диски могут оказаться и вовсе невостребованными.

      • CaptainFlint
        /#24611306 / +1

        В датацентрах, наверное, так можно. На больших объёмах выход дисков из строя становится не исключительной ситуацией, а статистической обыденностью. Но для домашнего пользователя переплачивать за NAS вдвое больше — кошельку может стать неуютно. Особенно если не задуматься об этом заранее.

  8. dlinyj
    /#24609624

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

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

    • SergeyMax
      /#24611624

      С одной только разницей: там (на пикабу) вообще не про SSD речь. Confirmation bias)

  9. Tsimur_S
    /#24610036

    Вообще, об этой проблеме известно как минимум с 2019 года. Однако в то время мало кто обратил внимание на эту информацию…


    Вообще о подобной проблеме известно как минимум с 2012 года, только в роли SanDisk был Crucial m4 и вместо 40 000 часов было 5200.
    www.storagereview.com/news/crucial-m4-0309-firmware-update-for-5200-hour-bug-released

  10. Didimus
    /#24610366 / +1

    Не совпадает ли это магическое число с периодом гарантии?

    • Tippy-Tip
      /#24611328 / +1

      Самый грубейший расчет показывает что это магическое число приблизительно совпадает не с гарантийным сроком, а с заявленным сроком службы:

      43830 часов /24/365,25 = 5 лет (обычно такой срок указывают для "бытовых" SSD).

      • Arlekcangp
        /#24611752 / +2

        Тоже такая мысль посетила. Причём тут ещё в статье написано, что уже была проблема 32768 часов... Она, очевидно, была следствием переполнения. Почему оставили только двухбайтовое целое? Ответ может быть, что люди которые это делали, считали что их продукт помрëт раньше, чем двухбайтоаый счётчик переполнится... А при фиксе, кто-то решил вставить костыль со словами: , "Ну столько то уж это барахло точно не проживëт"... И 32768 превратилось в 40000. Что тут сказать, версия идиотическая, но тем хуже если окажется действительностью... Интересно, сколько часов туда зашил новый патч? Остаётся надеяться, что не 65535...

      • vorphalack
        /#24615078

        вообще интересно, а 40000 ли там или всё же 40960?

    • 104u
      /#24611738 / +1

      Мне кажется, специально гробить ссд нет смысла, они и так сами по себе потихоньку дохнут, если вы об этом. А вот как можно написать такую прошивку, в которой дохнет контроллер из-за какого-то сраного счётчика часов, причем без возможности восстановления (если я это правильно понял) — вопрос крайне интересный

    • dimkoku
      /#24613388

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

  11. DarkWolf13
    /#24615064

    ....так, еще один повод проверить архивы резервных копий на разворачиваемость...а SanDisk расстроил, помню его как производителя твердотельных дисков еще с конца 90х, и казалось бы больших проблем не должно было быть, а оказалось что ошибка очень похожа на вышедший из под контроля или не отлаженный механизм устаревания. сомневаюсь что через 30 лет можно будет запустить какой нибудь современный накопитель, а вот старый MFM HDD на 20 МБ сейчас вполне запускается