На железячных форумах периодически поднимается тема про «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)
QuAzI
08.08.2022 12:39+2Любители подешевле так и не дали умереть этим бракоделам... а жаль... вот уж много лет как обхожу их стороной после жмени мёртвых флешек разных моделей
usernotfound_yet
08.08.2022 12:51-32для меня как владельца HDD статейки про смерть SSD всегда повод для умиления и попкорна. Когда я предупреждал - все улыбались, теперь моя очередь улыбаться.
и Пы.Сы. - я не страдаю от низкой скорости считывания, я просто обхожу ее стороной и пользуюсь ОЗУ (у нее еще пока циклы бесплатные, капиталисты пока до этого момента еще не добрались, но и это ненадолго, ибо "бесплатная работа еще и без подписки" не дает спокойно спать ночами всяким маркетологам и спецам по запланированному устареванию).
TimsTims
08.08.2022 12:58+12статейки про смерть SSD всегда повод для умиления
Вы не страдаете, но не значит, что остальным не нужны SSD. Плюс большинство статей прошлого касалось ограниченного ресурса ssd, связанного с их циклами перезаписи. А статья вообще о другом - о баге в прошивке. Точно такой-же баг мог в теории произойти и в HDD. Так-что это вообще не связанно с типом диска.
Пы.Сы. - я не страдаю от низкой скорости считывания и пользуюсь ОЗУ.
Вы не страдаете, а я страдаю. А как вы в ОЗУ игры храните например? Браузер долго запускается? Или вы просто не выключаете никогда никакие проги?
konst90
08.08.2022 13:45+32для меня как владельца HDD
Вы видимо не слышали про WD Green, которые парковали головки через 8 секунд бездействия, что в определённых моделях использования убивало диски за два-три года.
И таких примеров у разных производителей - море.
demitel
09.08.2022 07:18+1А ещё были диски Fujitsu, у которых таблица ошибок smart из-за отсутствия проверки могла вылезти за отведённые границы и шла перезапись каких-то важных заводских настроек, после чего винт умирал.
Inine
08.08.2022 14:03+2Помню, когда покупал в 2002 свой первый комп, то все друзья говорили мне "главное, не купи Дятла! И вообще, ну его Айбиэм этот, бери лучше Сигейт". Так что удачи верующим)
Didimus
08.08.2022 16:33Как раз после того купил Сигей с неправильно откалиброванным термодатчиком, он переставал писать во время работы. В гарантийку с таким дефектом его сдать не смог, так как там выполняли только тест чтения поверхности...
Dolios
08.08.2022 19:02+2Еще фуджики с циррозом примерно в то же время были..
vorphalack
10.08.2022 04:54цирроз и дятлы все же аппаратные были, причем цирроз проходил по статье «хотели как лучше, а получилось даже хуже чем обычно» :)
creker
08.08.2022 15:02+3я не страдаю от низкой скорости считывания, я просто обхожу ее стороной и пользуюсь ОЗУ
Базу на десяток ТБ в памяти мне разместите пожалуйста
hyperwolf
09.08.2022 12:20+1Ну запихайте несколько десятков терабайт логов в ОЗУ. Или базу схожего размера. Дома-то порнуху можно хоть на дискетах хранить, но мир не ограничен домашними ПК.
Demiourgos
09.08.2022 15:42Запланированное устаревание? Осень интересно.
Во-первых, насколько я понял, речь в статье идёт об ошибке.
Во-вторых, запланированного устаревание -- это жупел сторонников теории заговора. Оглянувшись вокруг можно увидеть много вещей которые, отработали не то чтобы гарантийный срок, а больше чем запланированный срок службы. Где запланированое устаревание?
KrivisKrivaitis
09.08.2022 21:43Во-вторых, запланированного устаревание -- это жупел сторонников теории заговора.
KorP
08.08.2022 12:55+7Бекапы на SSD? Красиво жить не запретишь :)
Новости о багах прошивок в 2019 и 2020 годах прошли, по сути, незамеченными.
В стораджовом чате активно обсуждали, не знаю, для кого это прошло незамеченным
Когда упал основной сервер HN, нагрузку перевели на резервный — но он тоже упал.
Естественно, возникает вопрос, как у главного IT-сайта в мире могут возникнуть такие проблемы с бэкапами?
При чём тут вообще бекап?
TimsTims
08.08.2022 13:06Тут вроде речь не про бэкапы на дисках, а бэкап-сервер, который работал на таких же дисках.
KorP
08.08.2022 13:08Пока я вижу желтушный заголовок про потерю бекапов и инфу по прошивкам двухлетней давности...
Что же касается резервного сервера - ну он резервный сервер, но не бекапы же :)
EvgeniyNuAfanasievich
08.08.2022 13:10+1Тоже самое хотел написать. потом подумал что есть такая штука как время развертывания из бэкапа и наверное хранить горячий (свежайший) бэкапчик на SSD не такая уж и глупая (в плане экономическом) идея.
KorP
08.08.2022 13:17Нет, она совершенно не глупая, и есть стораджовые вендоры, у которых нет дисковых массивов, которые её активно двигают в людей :) Другой вопрос, что позволить себе такое решение могут далеко не все, ввиду своей высокой стоимости. Тут нужно исходить из стоимости простоя сервисов и тд.
HepoH
08.08.2022 14:16+15На самом деле, на странице RAID в википедии есть короткий абзац, который выражает смысл этой статьи (помимо штуки с багом в прошивке):
Коррелированные сбои
Накопители в массиве, за исключением запасных («spare»), первое время часто имеют одинаковый возраст, подвергаются одинаковой нагрузке и воздействию окружающей среды, это нарушает предположения о независимой вероятности отказа дисков; сбои на самом деле статистически коррелированы. На практике шанс второго отказа перед первым восстановлением выше, чем вероятность случайных сбоев.
13werwolf13
08.08.2022 14:20+11устал объяснять клиентам почему в зеркало лучше ставить диски из разных партий, а лучше разных производителей.. в итоге один напоролся на одновременно вышедшую из строя пару дисков (слава бг системных а не с данными) и заказывая замену сам попросил чтобы были из рахных партий.
ruomserg
08.08.2022 14:55+8… а еще мы предупреждаем клиентов, что диски сидят на одной шине и на одном питании, а также в одном физическом месте. И это несет риски катастрофического отказа.
А потом мы спрашиваем клиента — какая у него в голове модель максимальной проектной аварии? А у него нету. Или он говорит, что хочет защититься от всего. А когда считаешь ему стоимость правильного резерва с географически разделенными локациями, и проч — он не хочет платить. И так и работает на как-то собранном в raid сервере…
Второй вариант ответа — давайте возьмем сервис в облаке/датацентре, там все будет 100% надежно. Почему? А так в ролике в интернете сказали (специалисты же врать не будут ...) :-(
SergeyMax
08.08.2022 15:28+1давайте возьмем сервис в облаке/датацентре, там все будет 100% надежно.
Обычно для облака указан процент доступности, и там нет указанной вами цифры.
ruomserg
08.08.2022 15:41+2Там сложно написано и непонятно… А в интернете на деньги маркетологов эхсперты пишут, что свой сервер — ненадежно, а облако или ЦОД — другое дело…
SergeyMax
08.08.2022 15:45Ну вообще так и есть, в среднем свой сервер + среднестатистический местный админ — это гораздо менее надёжная вещь, чем машина в облаке амазона.
ruomserg
08.08.2022 17:30+4Боюсь, что это очень зависит опять-таки от сценария МПА, который держит в голове клиент. Потому что теперь мы добавили канал связи, перестали управлять рисками внутри подрядчика, и отказались от экспертизы внутри компании, которая при аварии молга хоть что-то придумывать и делать. Да, экспертиза внутри компании бывает плохая и может даже сделать еще хуже чем если ничего не делать… Но теперь ее нет, и все что остается делать — это писать письма в поддержку…
В общем, безусловно — решение отдать сервер в облако меняет ландшафт рисков, но отнюдь их не устраняет.
И да, лучше всего работает локальный сервер с географически распределенным резервом и бэкапами (в то же облако). Но… денег же жалко, и экспертизы нет. А экспертизы нет, потому что всем жалко денег…SergeyMax
08.08.2022 20:30и отказались от экспертизы внутри компании,
Тут вон эксперт ниже спрашивает, что будет, если один диск отключить. И хоть вы зауправляйтесь своими рисками и сценариями, в среднем по больнице оно как-то так всегда и выглядит.
d2d8
08.08.2022 17:52+2Всю жизнь ставил зеркала из одинаковых дисков из одной партии из соображений того, чтоб диски были одинаковой скорости и объем до байтика сходился. И даже после выхода одного из дисков из строя менял сразу пару на опять же одинаковые. И только после этой статьи и комментариев до меня дошла пагубность данной практики, ведь зеркало создается не для "работы", а для "поломки". Век живи, век учись.
P.S. Правда пару раз попадал в небольшую неприятность когда приходилось менять один из пары на другую модель и вот там эти различия в пару байт мешали нормально восстановить md raid. Победить это не сложно или создавать изначально raid не на весь объем, но видимо тоже служило причиной использования абсолютно одинаковых дисков.
Loggus66
09.08.2022 09:25А как победить? Уменьшить ФС и RAID следом?
bugbringer
09.08.2022 09:32Когда я столкнулся с таким конфузом, у меня не вышло ничего, кроме следующего варианта - на новом диске создал новый рейд так, чтобы общий размер был чуть меньше диска. Потом перенос данных, потом подключение выжившего диска к новому. Увы, не самая быстрая операция.
arheops
09.08.2022 16:07А просто взять новый диск больше? Вообще у софт рейда на такой случай в конце пару мегабайт неиспользуемого пространства.
bugbringer
09.08.2022 17:04На тот момент была нехватка денег вплоть до того, что лучше потерять полдня, чем купить ещё один диск.
d2d8
10.08.2022 18:18Первые разы именно так и делал, по дороге вылезали какие-то проблемы, уже не вспомню какие, да и не быстро это было. Так что потом просто создавал на новой паре дисков рейд заново и копировал данные.
Revertis
08.08.2022 18:19-1Таааак, и тут я захотел отключить на время один диск из софтового райда (через mdadm), а потом вернуть его в райд. Такое можно нормально сделать? Чтобы нормально потом синканулся райд.
HepoH
08.08.2022 18:51Мне ещё ни разу не требовалось восстанавливать массив, но отключение диска "на время" мне видится равноценным ситуации "выхода диска из строя". Соответственно дальше у вас идут варианты в зависимости от типа массива, но в конечном итоге все равно нужно будет проводить процедуру восстановления массива.
Ну, разве что на обоих дисках данные останутся полностью неизменном виде.Revertis
08.08.2022 18:53-1Ну вот восстановление массива сложная операция вообще, если нет нагрузки на сервер?
HepoH
08.08.2022 18:56Не могу ответить, пока ни разу не доводилось выполнять. Знаю только, что в этот момент нагрузка на диски крайне высока, и это опасный момент в плане того, что если вышел из строя один диск, и вы восстанавливаете структуру массива, есть риск выхода других дисков из строя из-за интенсивной нагрузки и, собственно, корреляции выше.
saboteur_kiev
08.08.2022 23:00Почему крайне высокая?
В нормальном рейд контроллере можно выставить в процентах допустимую нагрузку для синхронизации дисков в массиве.
Вдобавок в рейде типа 10, выход из строя одного диска практически не влияет на производительность.
Итого, давим 5% мощности на синхронизаци. Нагрузка вырастет на не более чем 5%.HepoH
08.08.2022 23:42+3Повторюсь, не то чтобы я эксперт по рейдам, оперирую данными со всяких википедий.
В нормальном рейд контроллере можно выставить в процентах допустимую нагрузку для синхронизации дисков в массиве
У меня сформировалось ощущение, что аппаратными рейдами уже не пользуются в виду того, что те что на матери не очень, т.к. в случае чего, они не подхватятся в другой системе, а программный рейд можно спокойно переносить между аппаратурой. А внешние аппаратные в то же время дорогие, не давая каких-то мастхев фич. Возможно для корпоративных схд мои представления не верны.
Насчет крайне высокой, это я запомнил, когда про пятый рейд читал:
При выходе из строя одного диска надёжность тома сразу снижается до уровня RAID 0 с соответствующим количеством дисков n−1, то есть в n−1 раз ниже надёжности одного диска — данное состояние называется критическим (degrade или critical). Для возвращения массива к нормальной работе требуется длительный процесс восстановления, связанный с ощутимой потерей производительности и повышенным риском. В ходе восстановления (rebuild или reconstruction) контроллер осуществляет длительное интенсивное чтение, которое может спровоцировать выход из строя ещё одного или нескольких дисков массива. Кроме того, в ходе чтения могут выявляться ранее не обнаруженные сбои чтения в массивах cold data (данных, к которым не обращаются при обычной работе массива, архивные и малоактивные данные), препятствующие восстановлению. Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается и данные на нём восстановлению обычными методами не подлежат.
PowerMetall
09.08.2022 12:30+1Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается
У нас в компании как раз такое и произошло несколько лет назад.
Данные восстановили. Правда за очень долгий срок, в далеко не полном объёме, и ОЧЕНЬ недёшево (сисадмин отправлял СХД в контору, специализирующуюся на такого рода вещах)На СХД были пользовательские файлы, но самое главное - база данных MSSQL на пару терабайт. Базу, само собой, восстановить не вышло ((
st1373
09.08.2022 13:58я ставил тест на системе, аппаратный vs программный, ну вообщем аппаратный гораздо шустрее, точных цифр не помню, но до 5-10 раз, диски SATA-HDD. Крайний раз прислали сервер тоже уже с контроллером, но там все специфично.
ЗЫ может ли выйти 2 диска одновременно? запросто, поэтому я стал заводить raid6, ну кое-где и raid1, но дисков больше 2-х + желательно spare
saboteur_kiev
09.08.2022 20:00Насчет крайне высокой, это я запомнил, когда про пятый рейд читал:
Так это относится собственно именно к пятому рейду. У него есть проблемы с перформансом, зато он гораздо дешевле, чем зеркало и может быть почти таким же быстрым, как райд1 по чтению, но с некоторой отказоустойчивостью. Ну или есть еще 6-й рейд.
Как раз проблемы пятого рейда хорошо решает внешний рейд со своим отдельным контроллером, рассчитанным на нагрузки, а не тот, что встроен в материнку.
Опять таки внешний рейд контроллер обычно используется не просто как еще одна плата в системнике, а к нему уже прилагается отдельная корзина на много дисков, плюс поддержка хотсвопа, хот спейр, собственного аккумулятора на случай пропадания питания, всякое такое.
Naves
08.08.2022 19:24+1Начнется rebuild массива, это значит, что с первого диска прочитаются ВСЕ данные, и запишутся на вставленный заново диск. mdraid понятия не имеет какие сектора с данными у вас изменились с момента отключения диска.
Если на рабочем диске, с которого будет чтение, найдутся bad-блоки, то raid не соберется.
В идеале вам нужен третий диск, который вставите вместо одного старого, на него и делайте rebuild.
В крайнем случае перед "операцией" можно сделать resync массива, который возможно найдет дефекты на дисках, если они есть.
saboteur_kiev
08.08.2022 23:01Если массив большой, то с каждого диска прочитается немного данных, и сделают это не одновременно, а в продолжительный процент времени. Тем более, что порядочные контроллеры могут и так видеть нагрузку и на восстановление/синхронизацию тратить время простоя.
regs
08.08.2022 19:17+2Если Raid 1, то можно. Только если когда массив онлайн. Если отключить диск в офлайне, то при пуске массив не соберётся и станет поломанным Raid 0. При каждом пуске его придётся пересобирать вручную. Давняя проблема mdadm, но никого не волнует.
ZFS же запустится, но из офлайна запасные диски в используемые не перейдут. Только если какой-то диск пропал в онлайне, то spare диск перейдёт в inuse.
Revertis
08.08.2022 19:23+1Понятно. Значит лучше не теребить мой raid1. Но там всё равно сервер для бэкапов, если он сдохнет, то на основной сервер это не повлияет. Только придётся бежать за новыми дисками.
bugbringer
09.08.2022 09:22Если вопрос изначально в том, чтобы разнести диски по времени использования - чтобы они не вышли из строя в один день, то я бы от себя посоветовал альтернативный вариант. Добавить третий диск - по вкусу в качестве рабочего или хотспара. Для паранойи лучше хотспар, конечно. И можно спокойно ждать выхода из строя.
arheops
09.08.2022 19:29С какого перепугу не собереться масив если диск в офлайне отключить? Собереться, просто будет диск missing/failed, в зависимости от контролера. В madam будет missed.
Постоянно в офлайне отключаю.
CaptainFlint
08.08.2022 15:28+5Ну а практический вывод из этой истории такой, что в один RAID нежелательно ставить накопители одной модели, а тем более из одной партии (с серийными номерами подряд).
Сколько помню, всегда как раз рекомендовалось использовать максимально одинаковые диски, чтобы избежать дисбаланса в параметрах чтения-записи и связанных с ним потерь производительности. Да ещё и покупать в запас для будущей замены, так как когда диск сдохнет, в продаже скорее всего уже не окажется такой модели.
Но проблема с одновременностью, конечно, имеется; вот и гадай теперь, как быть…ruomserg
08.08.2022 17:33+1Да ну! Всегда просили ставить диски разных производителей — а если это невозможно, то хотя бы разных партий и разных дат поставок. Именно для того, чтобы избежать ситуации, когда вся партия имеет скрытый дефект…
v1000
08.08.2022 22:51вся партия имеет скрытый дефект…
В свое время массово начали выходить из строя диски одной модели и одной партии. После чего появился слух, что в порту при разгрузке немного уронили контейнер с этой партией дисков.
eptr
09.08.2022 02:34+3Но проблема с одновременностью, конечно, имеется; вот и гадай теперь, как быть…
Очень просто: скажем, каждые 3 месяца докупается один диск и меняется на один из тех, что был установлен в RAID'е с самого начала, и так -- пока не будет докуплено N - 1 дисков.
В результате, в RAID'е будут диски с "разбегом" в 3 месяца, а в запасе тоже будут диски, с частично отработанным ресурсом.
В дальнейшем, при выходе из строя дисков в RAID'е, логично будет заменять их на диски из запаса, выбирая такие из них, чтобы "разбег" по выработке ресурса дисков в RAID'е оставался относительно равномерным.
Риск того, что новые диски в самом начале массово начнут выходить из строя, невелик.
Да и никакие ухищрения при таком развитии событий не спасут.Но чем дальше от момента создания RAID'а, тем диверсифицированнее при таком подходе становится защита от флеш-моба дискового "падежа".
За уменьшение риска в одном месте приходится платить увеличением рисков в другом, а именно, -- тем, что запасные диски могут оказаться и вовсе невостребованными.
CaptainFlint
09.08.2022 02:55+1В датацентрах, наверное, так можно. На больших объёмах выход дисков из строя становится не исключительной ситуацией, а статистической обыденностью. Но для домашнего пользователя переплачивать за NAS вдвое больше — кошельку может стать неуютно. Особенно если не задуматься об этом заранее.
dlinyj
08.08.2022 16:32Буквально сегодня читал пост на известном ресурсе, о фиксации такой проблемы.
Так что, ситуация описанная в посте вполне себе реальная, увы.SergeyMax
09.08.2022 08:44С одной только разницей: там (на пикабу) вообще не про SSD речь. Confirmation bias)
Tsimur_S
08.08.2022 18:17Вообще, об этой проблеме известно как минимум с 2019 года. Однако в то время мало кто обратил внимание на эту информацию…
Вообще о подобной проблеме известно как минимум с 2012 года, только в роли SanDisk был Crucial m4 и вместо 40 000 часов было 5200.
www.storagereview.com/news/crucial-m4-0309-firmware-update-for-5200-hour-bug-released
Didimus
08.08.2022 19:54+1Не совпадает ли это магическое число с периодом гарантии?
Tippy-Tip
09.08.2022 03:32+1Самый грубейший расчет показывает что это магическое число приблизительно совпадает не с гарантийным сроком, а с заявленным сроком службы:
43830 часов /24/365,25 = 5 лет (обычно такой срок указывают для "бытовых" SSD).
Arlekcangp
09.08.2022 09:18+2Тоже такая мысль посетила. Причём тут ещё в статье написано, что уже была проблема 32768 часов... Она, очевидно, была следствием переполнения. Почему оставили только двухбайтовое целое? Ответ может быть, что люди которые это делали, считали что их продукт помрëт раньше, чем двухбайтоаый счётчик переполнится... А при фиксе, кто-то решил вставить костыль со словами: , "Ну столько то уж это барахло точно не проживëт"... И 32768 превратилось в 40000. Что тут сказать, версия идиотическая, но тем хуже если окажется действительностью... Интересно, сколько часов туда зашил новый патч? Остаётся надеяться, что не 65535...
104u
09.08.2022 09:17+1Мне кажется, специально гробить ссд нет смысла, они и так сами по себе потихоньку дохнут, если вы об этом. А вот как можно написать такую прошивку, в которой дохнет контроллер из-за какого-то сраного счётчика часов, причем без возможности восстановления (если я это правильно понял) — вопрос крайне интересный
dimkoku
09.08.2022 15:42Это не магическое число, на мой взгляд, а так называемое "запланированное устаревание", хотя я бы добавил великого рандома в "баг", чтобы оно не было столь очевидно.
DarkWolf13
10.08.2022 04:32....так, еще один повод проверить архивы резервных копий на разворачиваемость...а SanDisk расстроил, помню его как производителя твердотельных дисков еще с конца 90х, и казалось бы больших проблем не должно было быть, а оказалось что ошибка очень похожа на вышедший из под контроля или не отлаженный механизм устаревания. сомневаюсь что через 30 лет можно будет запустить какой нибудь современный накопитель, а вот старый MFM HDD на 20 МБ сейчас вполне запускается
YMA
Бэкапы по правилу "3-2-1" - не помним. И держим резервные копии на SSD.
Да уж...
v1000
Тем более что RAID это скорее про доступность данных, а не надежность. В свое время софтверный RAID 1 умудрился все данные испортить после ребилда, при этом сами диски были в порядке. Хотя, казалось бы, что сложного в банальном зеркалировании данных...
edo1h
очевидно, сложно определить какая из копий сектора верна, в raid1 нет соответствующей метаинформации (и если её добавить, то это ×2 к iops на запись).
в этом плане zfs правильно устроена, там есть merkle tree, которое позволяет валидировать данные, в том числе и в случае «рассинхрона» зеркала.
edo1h
скорее у автора статьи в голове каша, он не отличает резервные копии от raid
vorphalack
мы рейд покупали не для того, чтоб делать резервные копии, уволен! /s