Comments 50
Всегда поражаюсь подобным рассказам — читается прямо как детектив)
Рад, что всё закончилось более-менее хорошо.
А как так контроллер неправильно интерпретирует команду, что затирает не те блоки? И разве у производителей нет каких-либо тестов для проверки этого?
Рад, что всё закончилось более-менее хорошо.
А как так контроллер неправильно интерпретирует команду, что затирает не те блоки? И разве у производителей нет каких-либо тестов для проверки этого?
Есть, конечно. Но там внутри кода — почти как в ext4, чтение логов к которой привело автора в уныние, а ошибки в них правят куда меньше людей…
Детектив — не то слово, но всё-таки историю про радиоактивную кэш-память в Sun SPARC'е не переплюнуть )
Тут не все эту историю знают, будет здорово если вы поделитесь)
Блин, к сожалению никак не получаетя нагуглить этот триллер (
Суть была в том, что Sun сделала сервера на основе процессора UltraSPARC II. Там была внешняя кэш-память. Затем в течение целого года к инженерам поступали отчёты о необъяснимых падениях софта у клиентов. Причем анализируя дампы инженеры видели иногда полный бред: типа записи в память значения, а затем падение в том месте, где условное ветвление по записанному значению пошло по противоположному условию. Они искали ошибки везде где только можно, начиная от HDL АЛУ, в масках для производства чипов и так далее, но это не давало результата, пока один инженер не припер в шутку счетчик Гейгера. И тогда-то оказалось, что IBM отгружало Sun'у кэш-память, которая почему-то слегка светила альфа-частицами. ECC как водится не было, но самое главное, что потом выяснилось, что в IBM знали об этой проблеме, но не сказали Sun.
Суть была в том, что Sun сделала сервера на основе процессора UltraSPARC II. Там была внешняя кэш-память. Затем в течение целого года к инженерам поступали отчёты о необъяснимых падениях софта у клиентов. Причем анализируя дампы инженеры видели иногда полный бред: типа записи в память значения, а затем падение в том месте, где условное ветвление по записанному значению пошло по противоположному условию. Они искали ошибки везде где только можно, начиная от HDL АЛУ, в масках для производства чипов и так далее, но это не давало результата, пока один инженер не припер в шутку счетчик Гейгера. И тогда-то оказалось, что IBM отгружало Sun'у кэш-память, которая почему-то слегка светила альфа-частицами. ECC как водится не было, но самое главное, что потом выяснилось, что в IBM знали об этой проблеме, но не сказали Sun.
Начинать копать можно отсюда. Но интернет не был так развит ещё и материалов не много.
Прямо призрак Барракуды какой-то.
Хм а какой на самом деле размер сектора у SSD?
512 байт или 4Кб как у HDD последних версий. Если второе то есть вероятность что TRIM трём весь сектор на 4Кб, при этом если по каким то причинам кластер FS не попадает на физический кластер то может затираться кусок следующего кластера. Но верить в такое не очень хочется.
512 байт или 4Кб как у HDD последних версий. Если второе то есть вероятность что TRIM трём весь сектор на 4Кб, при этом если по каким то причинам кластер FS не попадает на физический кластер то может затираться кусок следующего кластера. Но верить в такое не очень хочется.
Разные SSD прикидываются дисками 512N (512 байт логический/физический сектор), 512E (4096 байт физический сектор, 512 байт логический) и 4KN (4096 байт логический/физический сектор), но разумеется «физический сектор» тут буквально понимать нельзя. Страницы больше, а блоки (стирание возможно с гранулярностью блока) еще больше. Например, для Samsung 840 Pro — 8КиБ страницы и 1МиБ блоки.
Естественно, хост про это не ничего не знает, его задача — передать от одного слоя абстракции (ФС) к другому слою (псевдо-HDD с 512 или 4096 секторами) информацию о секторах с невалидными (в результате удаления файлов) данными. Дальше уже контроллер SSD занимается сборкой мусора — из кусочков с невалидными данными собирает большой блок и стирает его.
Естественно, хост про это не ничего не знает, его задача — передать от одного слоя абстракции (ФС) к другому слою (псевдо-HDD с 512 или 4096 секторами) информацию о секторах с невалидными (в результате удаления файлов) данными. Дальше уже контроллер SSD занимается сборкой мусора — из кусочков с невалидными данными собирает большой блок и стирает его.
Никогда не понимал, что им мешает сообщать реальные размеры секторов. Ну скажи ты операционной системе честно, что ты 4096/1M.
Обратная совместимость. Остаётся только научить ОС работать с этим знанием, про мегабайтные сектора ни одна ОС не знает. Только-только всё улеглось с 4К-секторами, но 4К — это не только современная ОС + загрузка через EFI, а ещё и куча всяких нюансов с софтом, использующим блочную репликацию. В Linux помимо физических/логических секторов среди т.н. IO hints для блочных устройств есть ещё необязательные optimal_io_size и minimum_io_size. Какие-то СХД и SSD их сообщают, какие-то нет.
P.S. В некоторых SSD, например, в последних Toshiba под SAS3 есть возможность менять размер «физического» сектора при форматировании как раз для ликвидации тех самых проблем с репликацией. В Fusion IO ещё такое видел. Но, конечно, только те же 512 и 4096 вместе с их «толстыми» разновидностями.
P.S. В некоторых SSD, например, в последних Toshiba под SAS3 есть возможность менять размер «физического» сектора при форматировании как раз для ликвидации тех самых проблем с репликацией. В Fusion IO ещё такое видел. Но, конечно, только те же 512 и 4096 вместе с их «толстыми» разновидностями.
Тут есть интересная тонкость: 4К удалось «осилить» относительно малой кровью потому, что 512К сектора реально никому (кроме загрузчика) никогда интересны не были. Вся «серъёзная» работа в современных ОС идёт со страницами, а их размер (на x86) — как раз 4КиБ. Так что переход на 4КиБ оказался достаточно безболезненным.
Работа же с блоками большего размера требует либо переписывания всего на свете, либо создания специального слоя трансляции. Но кто будет делать подобный слой трансляции бесплатно если его можно выгодно продать в составе SSD?
Работа же с блоками большего размера требует либо переписывания всего на свете, либо создания специального слоя трансляции. Но кто будет делать подобный слой трансляции бесплатно если его можно выгодно продать в составе SSD?
А не подскажите, когда и в каких ОС планируется поддержка более емких секторов? Очень интересно! Просто обратная совместимость нужна, но и современные реалии тоже нажно учитывать.
Ничего не могу сказать про далёкое будущее, но сейчас никакой острой проблемы, IMHO, нет. Запись на SSD блоками меньше его «блока стирания» приводит лишь к неоптимальному расходу запаса чистых блоков, т.е. потеря производительности. Упомянутые minimum_io_size и optimal_io_size — это на самом деле не какая-то внутренняя особенность Linux, а вполне себе часть стандарта SPC-3 (т.е. для SCSI устройств). В спецификациях NVMe наверняка тоже что-то на этот счёт есть. Определённое приложение или компоненты ОС вполне могут использовать эти данные для оптимизации производительности.
Но зачем же жёстко запрещать, например, писать блоки меньше 1М — серверные SSD и так справится (есть большой кэш, много Over Provisioning, интенсивная сборка мусора), адесктопным сильно поможет TRIM, и никому не придётся переписывать тонны софта.
Но зачем же жёстко запрещать, например, писать блоки меньше 1М — серверные SSD и так справится (есть большой кэш, много Over Provisioning, интенсивная сборка мусора), адесктопным сильно поможет TRIM, и никому не придётся переписывать тонны софта.
Вам уже ответили, но пропустили важный этап, без которого понять ответ нельзя. Блоки, с которыми оперирует современный NAND огромны — куда больше, чем 512 байт или 4КиБ. Там речь зачастую идёт на мегабайты. Причём этих размеров не один, а два — вы можете писать «маленькие» страницы 4-8КиБ (и чем дальше, тем больше), но только поверх «прочищенных» блоков размером от 1-2МиБ (и чем дальше, тем больше). Потому что, грубо говоря, «нуль» в транзистор с плавающим затвором записать просто, а «единицу» — сложно.
И поверх всего этого нужно «эмулировать» обычный жёсткий диск со случайным доступом к данным. Весьма непростая задача, надо сказать…
И поверх всего этого нужно «эмулировать» обычный жёсткий диск со случайным доступом к данным. Весьма непростая задача, надо сказать…
Было бы отлично, если бы вы потом по результатам от Samsung сделали бы заметку. Всё же довольно солидная контора — интересно, как они подобные проблемы решают.
Что было после 19 июня авторы не сообщают? =(
Skynet перестал прятаться и восстал.
Месяц вместе с Samsung пытались воспроизвести проблему, но долго не получалось. Вчера сообщили, что наконец-то удалось.
Коротко: виновато ядро Linux. Ребята из Samsung подготовили патч, сегодня его должны представить.
1cloud, было бы неплохо обновить пост новой информацией.
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, было бы неплохо обновить пост новой информацией.
Коротко: виновато ядро Linux.Можно подробнее? Вот есть определенный SATA-протокол, ядро его как-то некорректно использовало, причем так, что это проявлялось только на некоторых накопителях?
Патч поможет другим накопителям из черного списка?
Скорее всего дело в каких-то таймингах. Я буквально на днях за'backup'ил машину, а при проверке sha512sum (ну паранойя у меня) у пары файлов сумма не совпала. И то же самое — мелкие файлы, в backup'е превращены в файлы такой же длины состоящие исключительно из нулей. Воспроизвести не удалось, но статью я сразу вспомнил.
На Samsung грешить не получится так как в машинке два накопителя — один Intel'овский SSD на 180GB (система, часто используемые файлы), другой — Seagate'овский HDD на 1TB (вот как раз на нём беда и наблюдалась).
P.S. При этом история с одним из битых файлов выла такая — в backup попали нули, а видел я нормальный файл. С другим файлом — наоборот. Такое ощущение что иногда ядро забывает читать данные…
На Samsung грешить не получится так как в машинке два накопителя — один Intel'овский SSD на 180GB (система, часто используемые файлы), другой — Seagate'овский HDD на 1TB (вот как раз на нём беда и наблюдалась).
P.S. При этом история с одним из битых файлов выла такая — в backup попали нули, а видел я нормальный файл. С другим файлом — наоборот. Такое ощущение что иногда ядро забывает читать данные…
Спасибо за дополнения — увидел заметку в рассылке ceph-users, но там не было на тот момент изменений о настолько плотной работе с вендором. Держите в курсе, пожалуйста, крайне любопытно, чем всё закончится.
Кстати, в самом списке рассылки тоже много интересного попадается об особенностях SSD, благо сейчас появляется всё больше кластеров SSD-only, да и в качестве кэша\журнала SSD must have.
Кстати, в самом списке рассылки тоже много интересного попадается об особенностях SSD, благо сейчас появляется всё больше кластеров SSD-only, да и в качестве кэша\журнала SSD must have.
Как-то опечалил захардкоженный блек-лист (причем, немаленький!) с моделями прямо в ядре. Новые диски выходят раньше заплаток, да и обновление ядра — вообще целая «история» для многих. Не говоря уже про то, что патчи из ванильного ядра попадают далеко не сразу в дистрибутивы.
>>Зная, что корень проблемы лежит где-то среди комбинаций программного обеспечения с приводами, мы установили на серверы с разными дисками идентичные программные пакеты. И? Ничего, файлы все равно были повреждены. Теперь можно было с уверенностью сказать, что проблема связана с дисками, а не с программным обеспечением.
А объясните логику этого заключения? Диски разные, ПО одинаковое, проблема наблюдается на всех дисках — значит, виноваты диски?
А объясните логику этого заключения? Диски разные, ПО одинаковое, проблема наблюдается на всех дисках — значит, виноваты диски?
Интересно, что среди всех обсуждающих этот странный текст заметили это только вы один. :-/
Не он один, мне тоже глаз резануло, но потом я решил, что это просто неудачная формулировка, автор чересчур положился на контекст. Непосредственно перед этим он говорит, что заподозрили диски, но разные версии софта не давали в этом убедиться. Чтобы проверить гипотезу, синхронизировали версии. Выяснилось, что да, [на тех же «подозрительных» дисках] файлы по-прежнему повреждались.
В отличие от перевода, в оригинале это звучало с несколько большей привязкой к контексту: «Nothing, the corruption appeared again.» Не просто «файлы были повреждены», а "the corrpution" — определённый артикль указывает на то, что это не абы какое повреждение каких-то файлов где-то там, а что речь идёт о конкретном (пока ещё гипотетическом) баге с конкретными моделями дисков, который как раз и пытаются выявить этим тестом.
В отличие от перевода, в оригинале это звучало с несколько большей привязкой к контексту: «Nothing, the corruption appeared again.» Не просто «файлы были повреждены», а "the corrpution" — определённый артикль указывает на то, что это не абы какое повреждение каких-то файлов где-то там, а что речь идёт о конкретном (пока ещё гипотетическом) баге с конкретными моделями дисков, который как раз и пытаются выявить этим тестом.
Ещё раз убедился в правильности принципа «В рейд — диски от разных производителей. Причём всегда, когда это хоть как-то возможно.» С тем, что какойнить seastern samshiba dbla4000 будет на 5% медленнее чем higital vobla 99, можно будет смириться, нервы дороже.
И чем бы этот «принцип» помог в описанной ситуации?
Тем, что mdadm выплюнул бы на всех серверах самсунги(или была бы найдена лажа только на них), что позволило бы локализовать проблему быстрее. А уже дальше спокойно разбираться в темпе вальса (заменив самсунг на что-то другое), «а фигли пять серверов выплюнули диски от одной конторы», а то можно получить вышеупомянутый «призрак барракуды» сразу на всех серверах с промежутком в десять минут(и куковать дальше, когда станет ясно, что за 1 минуту их всех не поднять). В результате к причине (глючный TRIM) пришли бы с меньшим бы геморроем на голову.
mdadm выплюнул бы на всех серверах самсунги(или была бы найдена лажа только на них
На основании чего это произошло бы, и почему, по-вашему, mdadm не «выплюнул» эти диски у авторов статьи?
На основании того, что если есть рейд, то очень полезно переодически мучать его командой verify. Которая в случае расхождения (для R5/6 и их производных) спокойно заявит об этом, в случае зеркала — увы нет. У авторов могло быть оно самое. У авторов могло не выплюнуть из-за отсутствия проверок дисков. И да, в скобках указано, что было бы в варианте без выплёвывания, раз уж авторы полезли под капот софтового рейда смотреть глазами
Заявит, если повезет — если записи в тот же набор блоков не было, и четность не пересчиталась заново. А если повезет — много ли толку? Вот у вас блок четности не соответствует данным на N дисках, здравствуй, silent data corruption, мы тебя нашли. Но на каком диске битый блок? Или это четность битая? И в результате — битый том целиком, а не сбойный конкретный диск.
Итого, если вы наберете рейды из разных дисков, получите сразу два эффекта:
1. У вас возникнут проблемы на большем количестве томов (два условных самсунга в паре, два интела в паре — один проблемный том и один целый, а две пары самсунг+интел — сразу два проблемных тома)
2. Под подозрение попадут все модели задействованных дисков.
Оно вам надо?
И, наоборот, если все массивы из дисков одного типа — вот тогда можно куда быстрее увидеть, что все проблемы — только на таких-то моделях.
Итого, если вы наберете рейды из разных дисков, получите сразу два эффекта:
1. У вас возникнут проблемы на большем количестве томов (два условных самсунга в паре, два интела в паре — один проблемный том и один целый, а две пары самсунг+интел — сразу два проблемных тома)
2. Под подозрение попадут все модели задействованных дисков.
Оно вам надо?
И, наоборот, если все массивы из дисков одного типа — вот тогда можно куда быстрее увидеть, что все проблемы — только на таких-то моделях.
У вас случайно есть ссылка на статью про «призрак барракуды»?
Заинтриговало, хочу ознакомиться.
Но в сети не могу найти, видимо не так ищу :)
Спасибо!
Заинтриговало, хочу ознакомиться.
Но в сети не могу найти, видимо не так ищу :)
Спасибо!
Вот у меня парочка Kingston SSDNow mSATA 120GB SMS200S3 в RAID1 средствами BTRFS, и вот раз в неделю при запуске fstrim улетали пачки файлов чаще всего из одной или нескольких папок, такое происходило 2 или 3 раза, потом прекратилось, уже месяца полтора всё в порядке, но улетали даже файлы в несколько мегабайт. Хорошо что делаются полные бекапы много раз каждый день и на другой диск.
Я так понимаю, основной вывод из статьи — нужно иметь резервные копии и уметь их быстро поднимать, желательно автоматически.
Я так понимаю, основной вывод из статьи — нужно иметь резервные копии и уметь их быстро поднимать, желательно автоматически.
Недавно имел проблему с Samsung SSD 840 PRO Series.
Писал код в Visual Studio, нажал F7 (сохранить и скомпилировать).
Винда (8.1) ушла в экран ошибки и перезагрузилась.
После загрузки обнаружил два файла с исходным кодом (которые как раз должны были сохраниться) заполненные одинаковым байтом.
Писал код в Visual Studio, нажал F7 (сохранить и скомпилировать).
Винда (8.1) ушла в экран ошибки и перезагрузилась.
После загрузки обнаружил два файла с исходным кодом (которые как раз должны были сохраниться) заполненные одинаковым байтом.
возможные решения, которые, в соответствии со списком выше, ранжировались от суперпростых до суперсложных.Интересное у них ранжирование. «Появился баг в файловой системе ext4» это значит тривиально, чуть ли каждый день случается. А на тупо помирающий SSD стали грешить в последнюю очередь.
И жаль не написали, отправили ли патч в ядро с новой регуляркой.
Забыли сказать самое главное — размер проблемы. Как часто случаются сбои? 1 из 100 дисков и 1 из 10000 это немного разные вещи.
Кстати, не первый случай кривого трима.
Я, помню, пару недель тупил над сырцами блочного стека линукса, пытаясь понять, почему mkfs.xfs сносит голову серверу.
Оказалось, WRITE SAME 16, DISCARD (аналог TRIM для SAS-SSD) приводил к зависанию диска, причём в крайне неудобном для enclosure положении, снося при этом связность и с другими дисками в enclosure. Задним умом я сейчас понимаю, что можно было бы сделать sg_reset для enclosure и обойтись без перезагрузки, но всё равно было неприятненько.
А команду (точнее, IOCTL 'BLKDISCARD') посылал mkfs.xfs.
Вендор долго сопротивлялся и рассказывал сказки про Windows Server, в котором пони и радуга, пока я не включил отладку HBA и не прислал полный лог IO, приводящий к зависанию. После этого прислали обновлённую прошивку (и даже не извинились).
Я, помню, пару недель тупил над сырцами блочного стека линукса, пытаясь понять, почему mkfs.xfs сносит голову серверу.
Оказалось, WRITE SAME 16, DISCARD (аналог TRIM для SAS-SSD) приводил к зависанию диска, причём в крайне неудобном для enclosure положении, снося при этом связность и с другими дисками в enclosure. Задним умом я сейчас понимаю, что можно было бы сделать sg_reset для enclosure и обойтись без перезагрузки, но всё равно было неприятненько.
А команду (точнее, IOCTL 'BLKDISCARD') посылал mkfs.xfs.
Вендор долго сопротивлялся и рассказывал сказки про Windows Server, в котором пони и радуга, пока я не включил отладку HBA и не прислал полный лог IO, приводящий к зависанию. После этого прислали обновлённую прошивку (и даже не извинились).
Хмм. Я был уверен, что корень зла лежит именно в mdadm. Лет пять назад похожая проблема была с нашими серверами, на которых стояли обычные HDD включеные в софтверный рейд на Ubuntu. Концы файлов также отсутствовали, последние изменения периодически не записывались. Проблема решилась покупкой и установкой hardware RAID контроллеров.
Ребята проделали огромную и стоящую работу по нахождению проблемы. Однако причина кроется по большей мере в кустарной архитектуре: сервера скорей всего были собраны самостоятельно из разных компонентов. При покупке готовых серверов проблемы, возможно, можно было бы избежать, т.к. компании-производители подвергают свои продукты нагрузочному тестированию на отказоустойчивость. Ну и SW RAID — это несерьезно, в основном для домашнего использования.
Ребята проделали огромную и стоящую работу по нахождению проблемы. Однако причина кроется по большей мере в кустарной архитектуре: сервера скорей всего были собраны самостоятельно из разных компонентов. При покупке готовых серверов проблемы, возможно, можно было бы избежать, т.к. компании-производители подвергают свои продукты нагрузочному тестированию на отказоустойчивость. Ну и SW RAID — это несерьезно, в основном для домашнего использования.
Будто вы не видели списки critical firmware updates для брендовых линеек… Или сраных fakeraid'ов в брендовых серверах, которые ставят туда с тем же успехом, как и не в брендовые.
> SW RAID — это несерьезно, в основном для домашнего использования.
Ага-ага. Только почему-то softraid живет и здравствует, а критические баги в железных рейдах чинят пачками каждый год.
Ага-ага. Только почему-то softraid живет и здравствует, а критические баги в железных рейдах чинят пачками каждый год.
Sign up to leave a comment.
Твердотельные накопители дали слабину