Оригато в хату, бисёнены
.
С вами нерегулярная рубрика "
Как проебать самосборное хранилище и не подать виду".
И сегодня, ради разнообразия, речь пойдёт не о кривых руках. Шучу, о них, конечно же. Но в этот раз хотя бы не о культяпках сборщиков.
Итак, вы зачем-то решили сами собрать хранилище из SSD. Понятно, что самая важная часть дисковго хранилища это (
внезапно) диски. Значит, вам нужны SSDшки, которые:
1. Дёшевы
2. SATA
3. От нормального вендора
4. Надёжны
5. Распространены
Поэтому ваш выбор падает на интеловскую линейку D3-S4510, которая вроде как по всем параметрам подходит. Размер диска пусть будет 2TB. Закупаете вы этих дисков по дешёвке и втыкаете в самосборную полку с суммарным полезным объёмом ~45TB и начинаете ЭКСПЛУАТАЦИЮ. Да такую, что
обои от стен отклеиваются. Спустя какое-то время всё более-менее устаканивается, LUNы больше не разваливаются и даже какой-то мониторинг появился.
А потом, одним недобрым утром, мониторинг радостно сообщает, что в SSD-полке диски пачками начали сыпать ошибками и отваливаться от контроллера. Ну мы ж теперь учёные, у нас даже ЗИП есть, поэтому сперва поменяем сбойные диски, а потом уже будем разбираться. Только вот зип кончается, а сбойные диски -- нет. Худо-бедно наскребаем рабочих дисков, стабилизируем систему, мигрируем с неё всё важное и начинаем разбираться.
Сперва идём в SMART, конечно же, а там реально счётчик B8 рапортует, что он преодолел аварийный порог. Ну ок, что за счётчик-то?
B8 | End-to-End Error Detection Count
Reports number of errors encountered during Logical Block Address (LBA) tag checks within the SSD data path. The normalized value begins at 100 and decrements by 1 for each LBA tag mismatch detected. The threshold value is 90.
"
Какого хуя, Intel?", вопрошаем мы. А
KB интела услужливо отвечает:
With previous firmware, there is a bug called channel hang on Intel® SSDs SSD D3-S4510 and SSD D3-S4610 with capacities of 3.84TB and 1.92TB.
Also S4510 M.2 form factors still on older firmware could see intermittent drive drop during initial boot.
Других подробностей вендор не сообщает, потому что пошли вы нахуй, вот почему. Зато пацаны из Lenovo на
подробности не жидятся:
Intel S4510 or S4610 SATA SSD (only 1.8 TB and 3.84 TB are affected) can experience the following issues after 1700+ cumulative idle hours.
Users can see critical errors under certain use conditions. The drive may report BAD_CONTEXT_2033, BAD_CONTEXT_1042 or excessive LBA mismatch (SMART attribute B8h) after 1700 hours of cumulative power-on idle time.
Once the error code is triggered, the drive will fail to respond on the bus.
Охуеть теперь, чо. Ладно, вальсируем.
-- Эй, Интел, может хоть подскажешь, как посмотреть параметр cumulative power-on idle time?
-- Конечно, друг. Посмотреть параметр cumulative power-on idle time ты можешь НИКАК, ахаха.
-- В смысле "никак"?
-- Ну вот так. Нет у нас такого параметра. Можешь посмотреть на drive power-on hours (09) и самостоятельно хуй к носу прикинуть.
Стоит ли говорить, что по прикидкам как раз 1700 часов на наших дисках и натикало, лол?
Что теперь делать? Нужно обновлять прошивку, конечно же. Но уже натикавшие в
End-to-End Error Detection Count ошибки апдейт не исправит.
А если нельзя сейчас так просто взять и обновить все диски в массиве? Тогда нужно использовать патентованный(c) workaround(tm) и горя не знать:
Users need to power cycle their servers/systems (once a month) in order to reset one of the counters so that the idle hour count will not reach 1700 hours and the issue will not happen.
И что у нас в итоге? Самопальная хранилка, фряха, zfs, заботливо поддерживающие всё это руки с очень малым радиусом кривизны и теперь ещё диски, из-за которых нужно ребутаться раз в месяц. Морали из всей этой хуйни у меня для вас нет, так что просто послушайте музыку:
https://music.yandex.ru/album/5792903/track/43516418