Все выглядело как банальный сбой, возникший посреди ночи. Один из серверов нашего поискового API прекратил индексирование по неизвестной причине. Поскольку мы в Algolia работаем над обеспечением высокой доступности и повышением отказоустойчивости, ничего плохого не случалось. Запросы к новому API были корректно перенаправлены на оставшиеся функционирующие машины кластера, а единственным, на ком хоть как-то сказался сбой, был разбуженный среди ночи инженер. Нужно было выяснить, что происходит.
Daemon NGINX, обеспечивающий передачу данных API по HTTP(S), был готов к работе с поисковыми запросами, но тут прервался процесс индексирования. Поскольку индексирование контролируется процессом supervise, то простое зацикливание было бы понятным, но полный выход из строя – это не нормально. Как позже выяснилось, файловая система оказалась доступной только для чтения. Хорошо, предположим, что всему виной космическое излучение; проблемы с файловой системой были исправлены, файлы восстановлены с другого рабочего сервера – все снова выглядело нормальным.
На следующий день файловая система уже другого сервера оказалась доступна только для чтения, через два часа – еще у одного, а у третьего – еще через час. Что-то было не в порядке. После того, как были восстановлены файловая система и все файлы, пришло время провести серьезный анализ, поскольку проблема не была единовременной. Мы выбрали программное обеспечение, которое участвует в работе стека системы хранения, и начали изучать недавно внесенные изменения.
Время найти причину и исправить её!
Сначала мы спросили себя, может ли проблема быть связана с работой нашего программного обеспечения? Может, мы используем небезопасные системные вызовы или обрабатываем данные небезопасным образом? Может, мы некорректно читаем и записываем файлы в память, перед их сбросом на диск?
- Файловая система: появился ли баг в файловой системе ext4? Можем ли мы случайно получить доступ к памяти, в которой хранятся таблицы размещения файлов?
- Mdraid: возможно, баг гнездится в утилите mdadm? Может, мы используем неподходящую конфигурацию?
- Драйвер: баг в драйвере?
- SSD: «умирает» SSD? Или того хуже – проблема в прошивке привода?
Мы предположили, в чем может заключаться проблема, и начали предлагать её возможные решения, которые, в соответствии со списком выше, ранжировались от суперпростых до суперсложных.
Пробежавшись по процедурам хранения нашего программного пакета, мы установили прерывания – теперь, если проблема возникнет снова, мы сможем точнее определить неисправные части. Но глядя на сигналы, которые посылал нам обработчик, мы пришли к выводу, что проблема не связана с нашим способом управления данными. Жаль.
Через час был поврежден еще один сервер. В этот раз мы изъяли его из кластера и начали исследовать бит за битом. Перед исправлением файловой системы мы увидели, что некоторые части наших файлов отсутствовали (были обнулены) – дата изменения файлов и размер остались прежними, просто некоторые их участки были заполнены нулями.
Маленькие файлы оказались полностью стертыми. Это было странно и заставило нас думать, что, возможно, наше приложение может получать доступ к определенным служебным частям памяти операционной или файловой систем, потому что это – единственный способ модифицировать файл без ведома файловой системы. Из-за того, что наше ПО написано на C++, начали рождаться безумные идеи и теории о том, что на самом деле происходит. Но мы зашли в тупик – системные области памяти были недоступны.
Может, проблема связана с ext4? Просмотр журнала изменений ядра в поисках проблемы, связанной с ext4 – это душераздирающее занятие. Практически в каждой версии мы находили исправленный баг, который (в теории) мог негативно сказаться на работе серверов. Должен сказать, что до чтения логов я спал спокойнее.
Мы распределили ядра версий 3.2, 3.10, 3.13 и 3.16 между наиболее часто повреждающимися машинами и ждали, пока какая-нибудь из заложенных «мин» взорвется. Взорвались все. Очередной тупик. Может, проблема заключена в ext4, просто с ней еще никто не сталкивался? Шанс, что мы оказались такими «везунчиками» был довольно мал, да и нам бы не хотелось останавливаться на этой версии. Вероятность того, что баг закрался в ext4, не была исключена полностью, но была практически нулевой.
Что, если проблема связана с mdadm? Просмотр журнала изменений вселил в нас уверенность, что корень проблемы определенно не здесь.
Уровень отчаяния достигал критической отметки, а мы все не могли остановить продолжающиеся ночные страничные нарушения. Мы потратили большую часть двух недель, просто выискивая повреждённые машины и восстанавливая их настолько быстро, насколько могли. Мы даже внедрили в наше ПО функцию, которая искала пустые блоки в индексных файлах, даже когда они не использовались, и предупреждала о них заранее.
Ни дня без повреждений
Машины продолжали «умирать» все чаще и чаще, но мы сумели автоматизировать процедуру восстановления на достаточно комфортном для нас уровне. При каждом падении мы пытались выявить закономерности в надежде найти наименьший общий знаменатель. У них у всех были одни и те же характеристики. Но с каждым разом кое-что становилось все яснее – проблема возникала только на части наших серверов.
Программный пакет был одинаковым на всех машинах, но их аппаратное обеспечение немного отличалось: отличались SSD, но все они были от одного производителя. Это очень нас встревожило, поэтому мы связались с поставщиком серверного оборудования и спросили, не сталкивались ли они с подобными проблемами раньше? Довольно сложно убедить человека из технической поддержки в существовании проблемы, которая периодически возникает на прошивках, обновленных до последней версии, но которую нельзя воссоздать самостоятельно. В этом мы не преуспели, однако это открытие стало нашей первой маленькой победой.
Зная, что корень проблемы лежит где-то среди комбинаций программного обеспечения с приводами, мы установили на серверы с разными дисками идентичные программные пакеты. И? Ничего, файлы все равно были повреждены. Теперь можно было с уверенностью сказать, что проблема связана с дисками, а не с программным обеспечением. Но было неясно, что меняет содержимое блока без ведома системы. Будет еще много подпорченных битов…
Дни превратились в рутину – с утра длительный душ, затем завтрак, восстановление поврежденных серверов, потом обед, снова восстановление поврежденных серверов, ужин и опять восстановление поврежденных серверов. Все это продолжалось до определенного дня, пока я, принимая утренний душ, не задался вопросом: «А насколько длинными являются последовательности испорченных битов?» Как оказалось, всегда терялись данные объемом 512 байт, что равняется одному блоку диска. Стоп, данные не просто терялись, а затирались нулями. Баг в аппаратном обеспечении? Или блок обнулился? Что может обнулить блок? TRIM! TRIM говорит SSD-приводу, какие пустые блоки следует обнулить. Но эти блоки не были пустыми, а другие типы SSD не страдали этой проблемой.
Чтобы проверить теорию, мы отключили TRIM на всех серверах. Это должно объяснить всё!
На следующий день не было повреждено ни одного сервера, два дня тишины, неделя… Кошмар закончился! По крайней мере мы так думали… Спустя месяц после определения проблемы один сервер перезапустился и загрузился с поврежденными данными. Повреждены были только маленькие файлы и сертификаты. Даже неправильное отключение сервера не может вызвать подобное.
Копаясь в исходном коде ядра, в поисках кода хоть как-то связанного с TRIM, мы наткнулись на чёрный список TRIM. Этот черный список настраивает специфическое поведение для определенных типов SSD-приводов, идентифицируя диск по названию с помощью регулярных выражений. Наши работающие SSD полностью удовлетворяли условиям, необходимым для нормальной работы TRIM, но для некоторых дисков нашего поставщика функционал был ограничен. Наши диски, которых коснулась проблема, не попадали ни в одну из категорий, поэтому им по умолчанию был разрешена вся функциональность TRIM.
Полная картина
В этот момент мы полностью осознали что происходит. Система принуждала TRIM стирать пустые блоки, команда неправильно интерпретировалась диском, в результате контроллер затирал те блоки, которые не должен был. Вот почему в некоторых файлах появлялись блоки с 512 байтами нулей, а файлы меньше этого размера стирались полностью. Нам повезло, что неправильно функционирующие команды TRIM попали в суперблок файловой системы, тем самым повредив его. Когда мы отключили TRIM, то большие файлы перестали повреждаться, но маленькие, которые однажды были выгружены в память и с того момента более не изменялись, имели две копии: верную, хранившуюся в памяти, и поврежденную, лежащую на диске. Проверка файлов ничего не находила, так как никогда не загружала копии этих файлов с диска, а просто читала их из памяти. Чтобы восстановить целостность данных была проведена тотальная перезагрузка серверов, и после долгих недель охота на призрака подошла к концу.
Мы проинформировали нашего поставщика оборудования о проблемных SSD, а они сообщили производителю. Мы заменили диски другими и не рекомендуем использовать любые SSD, которые определяются ядром Linux как плохие. Будьте осторожны, даже при выключенном TRIM в Ubuntu 14.04 планировщик cron раз в неделю запускает FSTRIM на всех разделах – секундное зависание хранилища будет вашей наименьшей проблемой.
Резюме
Неработающие SSD:
- SAMSUNG MZ7WD480HCGM-00003
- SAMSUNG MZ7GE480HMHP-00003
- SAMSUNG MZ7GE240HMGR-00003
- Samsung SSD 840 PRO Series недавно появился в черном списке 800 серии
- Samsung SSD 850 PRO 512GB попал как отдельно, под названием 850 Pro, так и в список 800 серии
Работающие SSD:
- Intel S3500
- Intel S3700
- Intel S3710
Оригинальный материал был опубликован 15 июня 2015 года
Дополнение от 16 июня: Часто во время обсуждений возникали предположения, что проблема возникла из-за недавнего новшества – команды Queued TRIM. Это не так. На наших дисках используются обычные команды TRIM, и проблемы, с которыми мы столкнулись, никак не относятся к последним изменениям в ядре Linux, связанным с отключением этих функций.
Дополнение от 17 июня: С нами связались представители компании Samsung, и мы предоставили им все системные спецификации и всю информацию о проблеме, которой располагали. Мы продолжим сотрудничать с Samsung и попытаемся разрешить эту проблему.
Дополнение от 18 июня: Мы только что провели телефонную конференцию с европейским филиалом Samsung и штабом Samsung в Корее. Их инженеры собираются нанести визит в один из наших дата-центров и совместно с нашим поставщиком серверного оборудования провести проверку упомянутых SSD на нашем программном и аппаратном обеспечении.
Дополнение от 19 июня: 22 июня, в понедельник, команда инженеров Samsung собирается проверить один из наших серверов в Сингапуре, и если они ничего не найдут на месте, то сервер отправится в штаб-квартиру Samsung в Корее для дальнейшего исследования.
Комментарии (50)
VBKesha
10.07.2015 12:31Хм а какой на самом деле размер сектора у SSD?
512 байт или 4Кб как у HDD последних версий. Если второе то есть вероятность что TRIM трём весь сектор на 4Кб, при этом если по каким то причинам кластер FS не попадает на физический кластер то может затираться кусок следующего кластера. Но верить в такое не очень хочется.
quartz64
10.07.2015 12:53+3Разные SSD прикидываются дисками 512N (512 байт логический/физический сектор), 512E (4096 байт физический сектор, 512 байт логический) и 4KN (4096 байт логический/физический сектор), но разумеется «физический сектор» тут буквально понимать нельзя. Страницы больше, а блоки (стирание возможно с гранулярностью блока) еще больше. Например, для Samsung 840 Pro — 8КиБ страницы и 1МиБ блоки.
Естественно, хост про это не ничего не знает, его задача — передать от одного слоя абстракции (ФС) к другому слою (псевдо-HDD с 512 или 4096 секторами) информацию о секторах с невалидными (в результате удаления файлов) данными. Дальше уже контроллер SSD занимается сборкой мусора — из кусочков с невалидными данными собирает большой блок и стирает его.
merlin-vrn
10.07.2015 13:33Никогда не понимал, что им мешает сообщать реальные размеры секторов. Ну скажи ты операционной системе честно, что ты 4096/1M.
quartz64
10.07.2015 13:45+4Обратная совместимость. Остаётся только научить ОС работать с этим знанием, про мегабайтные сектора ни одна ОС не знает. Только-только всё улеглось с 4К-секторами, но 4К — это не только современная ОС + загрузка через EFI, а ещё и куча всяких нюансов с софтом, использующим блочную репликацию. В Linux помимо физических/логических секторов среди т.н. IO hints для блочных устройств есть ещё необязательные optimal_io_size и minimum_io_size. Какие-то СХД и SSD их сообщают, какие-то нет.
P.S. В некоторых SSD, например, в последних Toshiba под SAS3 есть возможность менять размер «физического» сектора при форматировании как раз для ликвидации тех самых проблем с репликацией. В Fusion IO ещё такое видел. Но, конечно, только те же 512 и 4096 вместе с их «толстыми» разновидностями.khim
10.07.2015 14:43Тут есть интересная тонкость: 4К удалось «осилить» относительно малой кровью потому, что 512К сектора реально никому (кроме загрузчика) никогда интересны не были. Вся «серъёзная» работа в современных ОС идёт со страницами, а их размер (на x86) — как раз 4КиБ. Так что переход на 4КиБ оказался достаточно безболезненным.
Работа же с блоками большего размера требует либо переписывания всего на свете, либо создания специального слоя трансляции. Но кто будет делать подобный слой трансляции бесплатно если его можно выгодно продать в составе SSD?
splav_asv
10.07.2015 21:26Перейти принудительно на huge pages как вариант на таких системах, но там еще больше проблем возникнет.
gorodianskyi
10.07.2015 14:45А не подскажите, когда и в каких ОС планируется поддержка более емких секторов? Очень интересно! Просто обратная совместимость нужна, но и современные реалии тоже нажно учитывать.
quartz64
10.07.2015 15:08+2Ничего не могу сказать про далёкое будущее, но сейчас никакой острой проблемы, IMHO, нет. Запись на SSD блоками меньше его «блока стирания» приводит лишь к неоптимальному расходу запаса чистых блоков, т.е. потеря производительности. Упомянутые minimum_io_size и optimal_io_size — это на самом деле не какая-то внутренняя особенность Linux, а вполне себе часть стандарта SPC-3 (т.е. для SCSI устройств). В спецификациях NVMe наверняка тоже что-то на этот счёт есть. Определённое приложение или компоненты ОС вполне могут использовать эти данные для оптимизации производительности.
Но зачем же жёстко запрещать, например, писать блоки меньше 1М — серверные SSD и так справится (есть большой кэш, много Over Provisioning, интенсивная сборка мусора), адесктопным сильно поможет TRIM, и никому не придётся переписывать тонны софта.
khim
10.07.2015 13:28+1Вам уже ответили, но пропустили важный этап, без которого понять ответ нельзя. Блоки, с которыми оперирует современный NAND огромны — куда больше, чем 512 байт или 4КиБ. Там речь зачастую идёт на мегабайты. Причём этих размеров не один, а два — вы можете писать «маленькие» страницы 4-8КиБ (и чем дальше, тем больше), но только поверх «прочищенных» блоков размером от 1-2МиБ (и чем дальше, тем больше). Потому что, грубо говоря, «нуль» в транзистор с плавающим затвором записать просто, а «единицу» — сложно.
И поверх всего этого нужно «эмулировать» обычный жёсткий диск со случайным доступом к данным. Весьма непростая задача, надо сказать…
Sap_ru
10.07.2015 12:59+12Было бы отлично, если бы вы потом по результатам от Samsung сделали бы заметку. Всё же довольно солидная контора — интересно, как они подобные проблемы решают.
DragonFire
10.07.2015 13:42+4Что было после 19 июня авторы не сообщают? =(
artspb
18.07.2015 09:50Месяц вместе с Samsung пытались воспроизвести проблему, но долго не получалось. Вчера сообщили, что наконец-то удалось.
Samsung had a concrete conclusion that the issue is not related to Samsung SSD or Algolia software but is related to the Linux kernel. Samsung has developed a kernel patch to resolve this issue and the official statement with details will be released tomorrow, July 18 on Linux community with the Linux patch guide.
Коротко: виновато ядро Linux. Ребята из Samsung подготовили патч, сегодня его должны представить.
1cloud, было бы неплохо обновить пост новой информацией.
arabesc
18.07.2015 20:13Коротко: виновато ядро Linux.
Можно подробнее? Вот есть определенный SATA-протокол, ядро его как-то некорректно использовало, причем так, что это проявлялось только на некоторых накопителях?
Патч поможет другим накопителям из черного списка?khim
18.07.2015 21:01+1Скорее всего дело в каких-то таймингах. Я буквально на днях за'backup'ил машину, а при проверке sha512sum (ну паранойя у меня) у пары файлов сумма не совпала. И то же самое — мелкие файлы, в backup'е превращены в файлы такой же длины состоящие исключительно из нулей. Воспроизвести не удалось, но статью я сразу вспомнил.
На Samsung грешить не получится так как в машинке два накопителя — один Intel'овский SSD на 180GB (система, часто используемые файлы), другой — Seagate'овский HDD на 1TB (вот как раз на нём беда и наблюдалась).
P.S. При этом история с одним из битых файлов выла такая — в backup попали нули, а видел я нормальный файл. С другим файлом — наоборот. Такое ощущение что иногда ядро забывает читать данные…
heathen
10.07.2015 13:46+2Спасибо за дополнения — увидел заметку в рассылке ceph-users, но там не было на тот момент изменений о настолько плотной работе с вендором. Держите в курсе, пожалуйста, крайне любопытно, чем всё закончится.
Кстати, в самом списке рассылки тоже много интересного попадается об особенностях SSD, благо сейчас появляется всё больше кластеров SSD-only, да и в качестве кэша\журнала SSD must have.
nitso
10.07.2015 14:50+2Как-то опечалил захардкоженный блек-лист (причем, немаленький!) с моделями прямо в ядре. Новые диски выходят раньше заплаток, да и обновление ядра — вообще целая «история» для многих. Не говоря уже про то, что патчи из ванильного ядра попадают далеко не сразу в дистрибутивы.
pushist1y
10.07.2015 16:46+1>>Зная, что корень проблемы лежит где-то среди комбинаций программного обеспечения с приводами, мы установили на серверы с разными дисками идентичные программные пакеты. И? Ничего, файлы все равно были повреждены. Теперь можно было с уверенностью сказать, что проблема связана с дисками, а не с программным обеспечением.
А объясните логику этого заключения? Диски разные, ПО одинаковое, проблема наблюдается на всех дисках — значит, виноваты диски?
netto
11.07.2015 12:35Интересно, что среди всех обсуждающих этот странный текст заметили это только вы один. :-/
CaptainFlint
11.07.2015 14:54+1Не он один, мне тоже глаз резануло, но потом я решил, что это просто неудачная формулировка, автор чересчур положился на контекст. Непосредственно перед этим он говорит, что заподозрили диски, но разные версии софта не давали в этом убедиться. Чтобы проверить гипотезу, синхронизировали версии. Выяснилось, что да, [на тех же «подозрительных» дисках] файлы по-прежнему повреждались.
В отличие от перевода, в оригинале это звучало с несколько большей привязкой к контексту: «Nothing, the corruption appeared again.» Не просто «файлы были повреждены», а "the corrpution" — определённый артикль указывает на то, что это не абы какое повреждение каких-то файлов где-то там, а что речь идёт о конкретном (пока ещё гипотетическом) баге с конкретными моделями дисков, который как раз и пытаются выявить этим тестом.
JerleShannara
10.07.2015 19:14Ещё раз убедился в правильности принципа «В рейд — диски от разных производителей. Причём всегда, когда это хоть как-то возможно.» С тем, что какойнить seastern samshiba dbla4000 будет на 5% медленнее чем higital vobla 99, можно будет смириться, нервы дороже.
ildarz
11.07.2015 00:06И чем бы этот «принцип» помог в описанной ситуации?
JerleShannara
11.07.2015 02:11+4Тем, что mdadm выплюнул бы на всех серверах самсунги(или была бы найдена лажа только на них), что позволило бы локализовать проблему быстрее. А уже дальше спокойно разбираться в темпе вальса (заменив самсунг на что-то другое), «а фигли пять серверов выплюнули диски от одной конторы», а то можно получить вышеупомянутый «призрак барракуды» сразу на всех серверах с промежутком в десять минут(и куковать дальше, когда станет ясно, что за 1 минуту их всех не поднять). В результате к причине (глючный TRIM) пришли бы с меньшим бы геморроем на голову.
ildarz
13.07.2015 11:10mdadm выплюнул бы на всех серверах самсунги(или была бы найдена лажа только на них
На основании чего это произошло бы, и почему, по-вашему, mdadm не «выплюнул» эти диски у авторов статьи?JerleShannara
13.07.2015 14:44+1На основании того, что если есть рейд, то очень полезно переодически мучать его командой verify. Которая в случае расхождения (для R5/6 и их производных) спокойно заявит об этом, в случае зеркала — увы нет. У авторов могло быть оно самое. У авторов могло не выплюнуть из-за отсутствия проверок дисков. И да, в скобках указано, что было бы в варианте без выплёвывания, раз уж авторы полезли под капот софтового рейда смотреть глазами
ildarz
13.07.2015 15:35Заявит, если повезет — если записи в тот же набор блоков не было, и четность не пересчиталась заново. А если повезет — много ли толку? Вот у вас блок четности не соответствует данным на N дисках, здравствуй, silent data corruption, мы тебя нашли. Но на каком диске битый блок? Или это четность битая? И в результате — битый том целиком, а не сбойный конкретный диск.
Итого, если вы наберете рейды из разных дисков, получите сразу два эффекта:
1. У вас возникнут проблемы на большем количестве томов (два условных самсунга в паре, два интела в паре — один проблемный том и один целый, а две пары самсунг+интел — сразу два проблемных тома)
2. Под подозрение попадут все модели задействованных дисков.
Оно вам надо?
И, наоборот, если все массивы из дисков одного типа — вот тогда можно куда быстрее увидеть, что все проблемы — только на таких-то моделях.JerleShannara
13.07.2015 22:57Если массив из дисков одной модели, то можно очень быстро увидеть, что поздно пить боржоми.
Keiichi
15.07.2015 10:19У вас случайно есть ссылка на статью про «призрак барракуды»?
Заинтриговало, хочу ознакомиться.
Но в сети не могу найти, видимо не так ищу :)
Спасибо!
nazarpc
10.07.2015 20:51Вот у меня парочка Kingston SSDNow mSATA 120GB SMS200S3 в RAID1 средствами BTRFS, и вот раз в неделю при запуске fstrim улетали пачки файлов чаще всего из одной или нескольких папок, такое происходило 2 или 3 раза, потом прекратилось, уже месяца полтора всё в порядке, но улетали даже файлы в несколько мегабайт. Хорошо что делаются полные бекапы много раз каждый день и на другой диск.
Я так понимаю, основной вывод из статьи — нужно иметь резервные копии и уметь их быстро поднимать, желательно автоматически.
Wouw
10.07.2015 22:28Недавно имел проблему с Samsung SSD 840 PRO Series.
Писал код в Visual Studio, нажал F7 (сохранить и скомпилировать).
Винда (8.1) ушла в экран ошибки и перезагрузилась.
После загрузки обнаружил два файла с исходным кодом (которые как раз должны были сохраниться) заполненные одинаковым байтом.
ComodoHacker
10.07.2015 23:50+1возможные решения, которые, в соответствии со списком выше, ранжировались от суперпростых до суперсложных.
Интересное у них ранжирование. «Появился баг в файловой системе ext4» это значит тривиально, чуть ли каждый день случается. А на тупо помирающий SSD стали грешить в последнюю очередь.
И жаль не написали, отправили ли патч в ядро с новой регуляркой.
amarao
11.07.2015 07:11+7Кстати, не первый случай кривого трима.
Я, помню, пару недель тупил над сырцами блочного стека линукса, пытаясь понять, почему mkfs.xfs сносит голову серверу.
Оказалось, WRITE SAME 16, DISCARD (аналог TRIM для SAS-SSD) приводил к зависанию диска, причём в крайне неудобном для enclosure положении, снося при этом связность и с другими дисками в enclosure. Задним умом я сейчас понимаю, что можно было бы сделать sg_reset для enclosure и обойтись без перезагрузки, но всё равно было неприятненько.
А команду (точнее, IOCTL 'BLKDISCARD') посылал mkfs.xfs.
Вендор долго сопротивлялся и рассказывал сказки про Windows Server, в котором пони и радуга, пока я не включил отладку HBA и не прислал полный лог IO, приводящий к зависанию. После этого прислали обновлённую прошивку (и даже не извинились).
Throwable
13.07.2015 11:49-3Хмм. Я был уверен, что корень зла лежит именно в mdadm. Лет пять назад похожая проблема была с нашими серверами, на которых стояли обычные HDD включеные в софтверный рейд на Ubuntu. Концы файлов также отсутствовали, последние изменения периодически не записывались. Проблема решилась покупкой и установкой hardware RAID контроллеров.
Ребята проделали огромную и стоящую работу по нахождению проблемы. Однако причина кроется по большей мере в кустарной архитектуре: сервера скорей всего были собраны самостоятельно из разных компонентов. При покупке готовых серверов проблемы, возможно, можно было бы избежать, т.к. компании-производители подвергают свои продукты нагрузочному тестированию на отказоустойчивость. Ну и SW RAID — это несерьезно, в основном для домашнего использования.
grossws
13.07.2015 13:07+3Будто вы не видели списки critical firmware updates для брендовых линеек… Или сраных fakeraid'ов в брендовых серверах, которые ставят туда с тем же успехом, как и не в брендовые.
easy_john
13.07.2015 14:04+2> SW RAID — это несерьезно, в основном для домашнего использования.
Ага-ага. Только почему-то softraid живет и здравствует, а критические баги в железных рейдах чинят пачками каждый год.
Ktulhy
Всегда поражаюсь подобным рассказам — читается прямо как детектив)
Рад, что всё закончилось более-менее хорошо.
А как так контроллер неправильно интерпретирует команду, что затирает не те блоки? И разве у производителей нет каких-либо тестов для проверки этого?
khim
Есть, конечно. Но там внутри кода — почти как в ext4, чтение логов к которой привело автора в уныние, а ошибки в них правят куда меньше людей…
dmitrmax
Детектив — не то слово, но всё-таки историю про радиоактивную кэш-память в Sun SPARC'е не переплюнуть )
AStek
Тут не все эту историю знают, будет здорово если вы поделитесь)
dmitrmax
Блин, к сожалению никак не получаетя нагуглить этот триллер (
Суть была в том, что Sun сделала сервера на основе процессора UltraSPARC II. Там была внешняя кэш-память. Затем в течение целого года к инженерам поступали отчёты о необъяснимых падениях софта у клиентов. Причем анализируя дампы инженеры видели иногда полный бред: типа записи в память значения, а затем падение в том месте, где условное ветвление по записанному значению пошло по противоположному условию. Они искали ошибки везде где только можно, начиная от HDL АЛУ, в масках для производства чипов и так далее, но это не давало результата, пока один инженер не припер в шутку счетчик Гейгера. И тогда-то оказалось, что IBM отгружало Sun'у кэш-память, которая почему-то слегка светила альфа-частицами. ECC как водится не было, но самое главное, что потом выяснилось, что в IBM знали об этой проблеме, но не сказали Sun.
isden
> кэш-память, которая почему-то слегка светила альфа-частицами
А не выяснилось, почему так вообще было? Это же пипец какой-то просто.
dmitrmax
К сожалению, нет. Я читал историю от лица инженера Sun, думаю, что IBM с ними не поделилась из-за чего такое произошло.
catharsis
вероятно, естественная радиоактивность материала.
маловероятно обнаружить радиометром на базе счетчика Гейгера без целенаправленных исследований.
Sap_ru
Начинать копать можно отсюда. Но интернет не был так развит ещё и материалов не много.
dmitrmax
Эту статью я нашел, но она не повествует о том, как инженеры радели над этой проблемой. Просто упоминает этот факт и всё. А тот рассказ, который я читал, реально захватывает дух, как данный пост.