Комментарии 75
Та же проблема с прекращением работы raid10 в linux. В ближайшее время предоставим всем клиентам возможность вернуться на старую конфигурацию СХД.
(я всё ещё работаю над проблемой, подробности позже).
(я всё ещё работаю над проблемой, подробности позже).
Случаем не «raid10_make_request bug: can't convert block across chunks or bigger than ...»?
нет.
Пока рабочее предположение — raid1/10 deadlock, который поправили в коммите
d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf (после 3.3)
Но я не могу воспроизвести проблему в лаборатории (сейчас уже делаем 6к IOPS на полигоне, и ситуация не воспроизводится), так что проверить, «оно или нет» пока не могу.
Пока рабочее предположение — raid1/10 deadlock, который поправили в коммите
d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf (после 3.3)
md/raid1,raid10: avoid deadlock during resync/recovery.
If RAID1 or RAID10 is used under LVM or some other stacking
block device, it is possible to enter a deadlock during
resync or recovery.
This can happen if the upper level block device creates
two requests to the RAID1 or RAID10. The first request gets
processed, blocks recovery and queue requests for underlying
requests in current->bio_list. A resync request then starts
which will wait for those requests and block new IO.
But then the second request to the RAID1/10 will be attempted
and it cannot progress until the resync request completes,
which cannot progress until the underlying device requests complete,
which are on a queue behind that second request.
So allow that second request to proceed even though there is
a resync request about to start.
This is suitable for any -stable kernel.
Но я не могу воспроизвести проблему в лаборатории (сейчас уже делаем 6к IOPS на полигоне, и ситуация не воспроизводится), так что проверить, «оно или нет» пока не могу.
Ну ребята!
Что то вы зачастили.
Что то вы зачастили.
Ровно та же проблема. После восстановления все диски машин будут перенесены. Я отчаялся решить проблему в доступных версиях ядра.
Беда.
Я всем вас советую, даже несколько машин людям настроил (фактически, привел клиентов за ручку) — а теперь такая фигня.
Надеюсь, это последний сбой в текущем году.
Я всем вас советую, даже несколько машин людям настроил (фактически, привел клиентов за ручку) — а теперь такая фигня.
Надеюсь, это последний сбой в текущем году.
НЛО прилетело и опубликовало эту надпись здесь
После аварии всем желающим будет предложено перенести диски на некластеризованное хранилище, аналогичное используемому в первом пуле.
Что с этим делать пока не знаю, следующая попытка перевода с raid10 на комбинацию raid1 + 0 (это не одно и то же).
В долгосрочной перспективе мы будем искать варианты принципиального решения проблемы (проприентарные решения, смена схемы построения массивов и т.д.).
Врят ли кого-то это утешит, но подобные аварии нам крайне болезенны, т.к. мы несём одновременно имиджевые, прямые денежные (компенсации), косвенные денежные (недопоставленные услуги) и ресурсные (время специалистов на устранение) потери. Соответственно, мы приложим все усилия для устранения подобного.
Что с этим делать пока не знаю, следующая попытка перевода с raid10 на комбинацию raid1 + 0 (это не одно и то же).
В долгосрочной перспективе мы будем искать варианты принципиального решения проблемы (проприентарные решения, смена схемы построения массивов и т.д.).
Врят ли кого-то это утешит, но подобные аварии нам крайне болезенны, т.к. мы несём одновременно имиджевые, прямые денежные (компенсации), косвенные денежные (недопоставленные услуги) и ресурсные (время специалистов на устранение) потери. Соответственно, мы приложим все усилия для устранения подобного.
Что с этим делать пока не знаю, следующая попытка перевода с raid10 на комбинацию raid1 + 0 (это не одно и то же).
Как так? Знаю 1+0, знаю 0+1, но это подмножества RAID10, а не отдельные типы массивов.
raid10 — это отдельный модуль ядра linux, который работает несколько иначе чем совокупность модулей raid1+ raid0
Логически — нет. Фактически — разный код, разный модуль ядра, и даже разное поведение. с raid10 чтение идёт со всех копий, а с raid1 — только с одной (со второй копии читается только в случае аварии).
НЛО прилетело и опубликовало эту надпись здесь
В прошлый раз вернули все деньги, потраченные на новом облаке.
НЛО прилетело и опубликовало эту надпись здесь
Да кто ж спорит? Я вообще не в курсе, будет ли в этот раз компенсация.
А серьезной компании, у которой 2 интернет-магазина нужно иметь план «Б» на такой случай.
Чтобы за полчаса продолжить работу на резервном хостинге.
Это не трудно автоматизировать.
А серьезной компании, у которой 2 интернет-магазина нужно иметь план «Б» на такой случай.
Чтобы за полчаса продолжить работу на резервном хостинге.
Это не трудно автоматизировать.
компенсация будет. Вероятнее всего, уже в апреле (на следующей неделе). Точный размер зависит от того, сколько займёт времени оставшаяся часть восстановления.
(Единственным плюсом ситуации является то, что flashcache полностью сохранил содержимое кеша, т.е. никаких потерь данных не планируется — будет эквивалент «принудительного отлкючения» для виртуальной машины).
(Единственным плюсом ситуации является то, что flashcache полностью сохранил содержимое кеша, т.е. никаких потерь данных не планируется — будет эквивалент «принудительного отлкючения» для виртуальной машины).
Подскажите как автоматизировать? Или даже не автоматизировать а быстро переключиться?
Допустим есть у меня копия сайта, но днс ведь может и больше чем пол часа обновляться
Допустим есть у меня копия сайта, но днс ведь может и больше чем пол часа обновляться
НЛО прилетело и опубликовало эту надпись здесь
Если меняется только A запись, а не NS сервер, выставить TTL в 5 минут, DNS обычно обновляется в течении 10ти минут.
Идеальный вариант, на мой взгляд — делать все автоматически. Проверять каждые 15 минут сервер, и если он не откликается — запускать скрипт распаковки бэкапов на резервном сервере и сразу переключать записи ДНС.
У меня обновление происходит 10-30 минут, обычно. Вот тут говорят, что можно сразу все прописать через SRV и будет типа ДНС балансировка. Не проверял, не знаю.
Понятно, что свежие бэкапы должны всегда быть. А резервный сервер можно даже выключать, когда не нужен (и не платить за него, соответственно, если мы про облака).
Я не серьезная компания, поэтому сделал бы вот так, просто bash скриптами.
А серьезные компании могут и железный балансировщик поставить, и вообще держать 2 сервера одинаковых на разных площадках. На эту тему информации навалом.
У меня обновление происходит 10-30 минут, обычно. Вот тут говорят, что можно сразу все прописать через SRV и будет типа ДНС балансировка. Не проверял, не знаю.
Понятно, что свежие бэкапы должны всегда быть. А резервный сервер можно даже выключать, когда не нужен (и не платить за него, соответственно, если мы про облака).
Я не серьезная компания, поэтому сделал бы вот так, просто bash скриптами.
А серьезные компании могут и железный балансировщик поставить, и вообще держать 2 сервера одинаковых на разных площадках. На эту тему информации навалом.
*вопрос
А если указать у домена 4 ns записи (по 2 на хостера), при стабильной работе первой площадки на второй домен не привязан, когда падает первая привязываю домен ко второй, поднимаю всё из бэкапа и по логике имею рабочий сайт. Или я не прав?
А если указать у домена 4 ns записи (по 2 на хостера), при стабильной работе первой площадки на второй домен не привязан, когда падает первая привязываю домен ко второй, поднимаю всё из бэкапа и по логике имею рабочий сайт. Или я не прав?
Так будет гораздо дольше.
Получается смена NS сервера домена, а это будет обновляться в течении суток. Однозначно не вариант.
Либо балансировка (разной степени сложности), либо быстро переключаем и ждем обновления.
Получается смена NS сервера домена, а это будет обновляться в течении суток. Однозначно не вариант.
Либо балансировка (разной степени сложности), либо быстро переключаем и ждем обновления.
Можно пользоваться cloudflare, там смена сервера происходит очень быстро, достаточно указать новые данные и все.
Плюс это вообще можно автоматизировать с помощью ddclient.
Плюс это вообще можно автоматизировать с помощью ddclient.
НЛО прилетело и опубликовало эту надпись здесь
Именно из-за резервирования мы сейчас и столкнулись с этой проблемой. Ошибка возникает синхронно (лаг в 20 минут) на обоих узлах кластера.
Ошибка ровно так же: /dev/md100 не исполняет запросы и не возвращает ошибки. Составляющие его диски работают без проблем. Текущее подозрение — проблемы в raid10 (модуле).
Ошибка ровно так же: /dev/md100 не исполняет запросы и не возвращает ошибки. Составляющие его диски работают без проблем. Текущее подозрение — проблемы в raid10 (модуле).
НЛО прилетело и опубликовало эту надпись здесь
Никто не умеет переключать хранилища между ДЦ. Проблема в СХД, а не в хостах виртуализации. Виртуалки между ДЦ гонять — никаких особых проблем. Проблема в репликации дисков. А текущая проблема: кластер (в котором репликация) даёт сбой почти синхронно в определённых ситуациях.
Мы про то, чтобы в случае аварии продолжить работу вообще на другом хостинге с минимальными потерями.
Чтобы бэкапы были под рукой, скрипты для разворачивания, обновления, и т.д.
Если бизнес серьезный — такие вещи должны быть предусмотрены и продуманы. Даже я свои микросайты бэкаплю и сохраняю за пределами хостинга — ни на кого не надеюсь.
P.S. И вообще, не отвлекайтесь на нашу болтовню — работать надо!
Чтобы бэкапы были под рукой, скрипты для разворачивания, обновления, и т.д.
Если бизнес серьезный — такие вещи должны быть предусмотрены и продуманы. Даже я свои микросайты бэкаплю и сохраняю за пределами хостинга — ни на кого не надеюсь.
P.S. И вообще, не отвлекайтесь на нашу болтовню — работать надо!
Мне ещё пол-часа ждать окончания синка. Основная проблема именно в этом — проблема проявляется при наличии resync/checking, его невозможно отменить (стандартны idle и т.д. не работают), а появление нагрузки параллельно с ним приводит к описанной проблеме.
Если бы не это, то ребут узла бы никто и не заметил, в крайнем случае даунтайм на 10 минут.
Пока эта сволочь не досинкается, я не могу поднимать iscsi.
Если бы не это, то ребут узла бы никто и не заметил, в крайнем случае даунтайм на 10 минут.
Пока эта сволочь не досинкается, я не могу поднимать iscsi.
NetApp в прошлом году хвалился насчет cross-site replication with FT
Понимаете, тут есть важный момент:
если у меня падает узел, то я просто ввожу в строй другой такой же и он продолжает исполнять машину.
А с сторами нельзя «другой такой же». Надо именно этот. Это означает, что если у нетаппа (я не клевещу, я просто предполагаю) случится бага в кластерном софте, которая затронет все узлы кластера, то они упадут ровно так же одновременно. И их нельзя будет заменить «другими».
В этом вся и драма. Когда у нас на одной из нод закозлил процессор (да, такое тоже бывает), даунтайм в 5 минут заметило 4 человека из 45. Просто потому, что ноду заменили и продолжили работу. А вот стор «взять и заменить» можно, только клиенты не одобрят.
если у меня падает узел, то я просто ввожу в строй другой такой же и он продолжает исполнять машину.
А с сторами нельзя «другой такой же». Надо именно этот. Это означает, что если у нетаппа (я не клевещу, я просто предполагаю) случится бага в кластерном софте, которая затронет все узлы кластера, то они упадут ровно так же одновременно. И их нельзя будет заменить «другими».
В этом вся и драма. Когда у нас на одной из нод закозлил процессор (да, такое тоже бывает), даунтайм в 5 минут заметило 4 человека из 45. Просто потому, что ноду заменили и продолжили работу. А вот стор «взять и заменить» можно, только клиенты не одобрят.
да, я тоже сразу про это вспомнил
Как бы это меркантильно не звучало, но потеря клиентов интернет-магазина ввиду лежащего хостинга — не вина хостера. Факапы бывают абсолютно у всех, это нужно всегда учитывать. И не перекладывать свою ответственность перед клиентами на вышестоящего поставщика услуг
Аналогично. 2 моих инет магазина лежат, плюс сайты заказчиков.
Мозг съедают. :(
Мозг съедают. :(
Хорошо, что я оставил сервер в старом пуле…
Как это сделать? :) Как-то не задумывался, а сейчас вот пришлось(
Просто не удалял давно созданный, до «Санкт-Петербург (2)», сервер.
Нужно было создать машину до 17 октября 2011, и после запуска нового облака — не переходить на него.
Увы… не успел…
А я дурак, перешел на новый пул и старую машину удалил.
Заманили снапшотами =(
Заманили снапшотами =(
Не люблю сам себя ругать, но в старом пуле от аварий прошлого года ничего не защищает — просто стабилизировавшася конфигурация. А авария на СХД старого вида может приводить потенциально к потери части данных, бывших «в пути» на запись. В новой конфигурации такого не может быть (ок, не буду категоричным, таких мест не планировалось).
В течение пары дней я подготовлю и протестирую СХД старого образца и предоставлю всем желающим возможность перенести на неё диски.
В течение пары дней я подготовлю и протестирую СХД старого образца и предоставлю всем желающим возможность перенести на неё диски.
Да я понимаю… Облако — сложная гигантская система, и вам большое спасибо за проектирование и поддержку этого монстра. Лично для меня это единственный разумный вариант (финансы не позволяют держать реальные железки, а шаред-хостинги я уже забыл как страшный сон).
Просто поспешил я сносить свою тачку со старого пула. Обратно переносить уже не буду, даже если будет возможность. Буду надеятся, что в новом пуле все исправите =)
Просто поспешил я сносить свою тачку со старого пула. Обратно переносить уже не буду, даже если будет возможность. Буду надеятся, что в новом пуле все исправите =)
Кредит доверия исчерпан практически полностью.
Почему многие думают, что размещение сайта в облаке позволяет забыть об отказоустойчивости на уровне своего приложения. Если сайт для бизнеса критичен, то будте добры держать резервную копию ресурса с лагом 5 -10 минут, а не надеятся что облако никогда не упадет.
Абсолюто верно. Именно так я всегда стараюсь настраивать работу клиентам для более-менее важных сайтов.
2-й дублирующий VPS в другом датацентре/городе/стране. Для синхронной репликации мастер-мастер MySQL — использую Galera или Tungsten + раз в 5 мин. rsync ФС на контент, конфиги, внетреннюю панель управления, etc… + TTL 1-5 мин. на A-type запись в DNS для доменов для оперативной (5-10 мин.) смены IP-адреса сайтов в случае необходимости. Дополнительно можно использовать 3-й VPS в качестве frontend-а c минимальными ресурсами (от 256Mb RAM) для балансировки/авто-переключения между серверами (nginx).
Для контента можно вобще использовать распределенную ФС GlusterFS, но в этом случае получим заментое снижение производительности сайтов с большим к-вом мелких файлов, поэтому rsync раз в 5 мин. на контент сайта вполне достаточно. В итоге получаем отказоустойчивую платформу для хостинга сайта/сайтов из 2х-3х VPS в рагдных датацентрах. Round-robin DNS балансировку не желательно использовать, т.к. в случае падения одного из серверов, запросы будут продолжать поступать на не рабочий сервер. Таким образом, в случае падения основного сервера, веб-проекты продолжат работу на резервном VPS в течении 5-10 мин., а после возобновления нормальной работы основного сервера, сайты могут быть переключены обратно на основной сервер без потери данных, т.к. MySQL базы и контент на основном сервере засинхронизируются с резервного, после восстановления нормальной работы основного сервера. Если что, могу подсказать в ЛС или тут.
2-й дублирующий VPS в другом датацентре/городе/стране. Для синхронной репликации мастер-мастер MySQL — использую Galera или Tungsten + раз в 5 мин. rsync ФС на контент, конфиги, внетреннюю панель управления, etc… + TTL 1-5 мин. на A-type запись в DNS для доменов для оперативной (5-10 мин.) смены IP-адреса сайтов в случае необходимости. Дополнительно можно использовать 3-й VPS в качестве frontend-а c минимальными ресурсами (от 256Mb RAM) для балансировки/авто-переключения между серверами (nginx).
Для контента можно вобще использовать распределенную ФС GlusterFS, но в этом случае получим заментое снижение производительности сайтов с большим к-вом мелких файлов, поэтому rsync раз в 5 мин. на контент сайта вполне достаточно. В итоге получаем отказоустойчивую платформу для хостинга сайта/сайтов из 2х-3х VPS в рагдных датацентрах. Round-robin DNS балансировку не желательно использовать, т.к. в случае падения одного из серверов, запросы будут продолжать поступать на не рабочий сервер. Таким образом, в случае падения основного сервера, веб-проекты продолжат работу на резервном VPS в течении 5-10 мин., а после возобновления нормальной работы основного сервера, сайты могут быть переключены обратно на основной сервер без потери данных, т.к. MySQL базы и контент на основном сервере засинхронизируются с резервного, после восстановления нормальной работы основного сервера. Если что, могу подсказать в ЛС или тут.
НЛО прилетело и опубликовало эту надпись здесь
У меня машина поднялась и работает как ни в чем не бывало.
НЛО прилетело и опубликовало эту надпись здесь
Отчёт о произошедшем:
После прошлой аварии был найден баг в ядрах 3.1/3.2 (и подтверждён в 3.3), приводящий к падению хоста в следующей конфигурации:
raid10 (минимум 4 диска)
в цикле hdparm -y на два диска из этого массива
какая-то дисковая активность на raid.
После того как ошибка была подтверждена было принято решение о даунгрейде на 3.0 (в которой этой ошибки нет).
В ходе даунгрейда (8:00-10:30) один хост был успешно переведён на 3.0. Тогда же была обнаружены проблемы с диском в одном из массивов (io error, pending sectors). Диск был заменён, начался ребилд.
(всё это время клиентов обслуживала оставшаяся половинка)
Узел был введён в кластер, но без обслуживания клиентов (в secondary режиме).
Примерно в 11, после перехода drbd в UpToDate/UpToDate режима, оставшийся (необновлённый и планируемый к обновлению) узел показал тот самый трейс, который и планировалось устранить.
Обслуживание клиентов переключилось на вторую половинку (обновлённую).
В 11:15 мы столкнулись с багом (описание ниже), который, как выяснилось, был отличен от бага с падением машины, который привёл к прекращению работы raid10 на первой половинке кластера. Вторая половинка кластера в этот момент начала checking после перезагрузки (о проблемах от этого — в описании бага).
Для решения проблемы пришлось перезагрузить хранилища, дождаться завершения rebuild/checking (самая долгая часть) и скинуть содержимое кеша (raid на SSD) на диски. После этого (примерно 16:10) начался запуск машин. К 16:30 запуск закончился. По нашим данным (за вычетом даунтайма) повреждений данных у машин не было, запустилось и работает 100% из них (возможно кому-то надо будет на консоли согласиться с запуском fsck).
Теперь главное — что за баг?
к сожалению, воспроизвести его в лаборатории нам не удалось (сейчас мы полностью воссоздаём весь стек устройств и точную конфигурацию и будем её мучить, чтобы достоверно поймать проблему).
Симптомы:
При запуске любых асинхронных операций mdadm (checking, resync) и наличии нагрузки raid10 прекращает обслуживать запросы. Это выглядит следующим образом:
dd if=/dev/md2 of=/dev/null bs=512 count=1 iflag=direct
просто не завершается.
Ровно так же не завершаются все остальные запросы (от iscsi target и других компонент). Все диски, из которых состоит raid10 прекрасно работают и не показывают снижения скорости.
Я не могу сейчас сказать условия возникновения этой проблемы, но точно могу сказать, что она воспроизводится гарантированно.
В настоящий момент мы запретили любые самостоятельные операции raid10, подняли оба узла.
Косвенной причиной сбоя стали профилактические работы, настоящей — неожиданная ошибка в работе raid10 (вместо того, чтобы из нескольких ненадёжных дисков сделать надёжный массив, он из нескольких надёжных дисков сделал шути-что).
Наши меры: воспроизведение ошибки в лаборатории, изучение условий возникновения, поиск решения. В течение этого времени — сохранение статуса кво без каких-либо манипуляций над СХД, которые могут привести к запуску проверки массивов.
Дальнейшие меры — если нам удастся локализовать и исправить ошибку, исправить её. Если нет — поиск альтернативных решений.
Компенсация за простой машин будет предоставлена на следующей неделе.
После прошлой аварии был найден баг в ядрах 3.1/3.2 (и подтверждён в 3.3), приводящий к падению хоста в следующей конфигурации:
raid10 (минимум 4 диска)
в цикле hdparm -y на два диска из этого массива
какая-то дисковая активность на raid.
После того как ошибка была подтверждена было принято решение о даунгрейде на 3.0 (в которой этой ошибки нет).
В ходе даунгрейда (8:00-10:30) один хост был успешно переведён на 3.0. Тогда же была обнаружены проблемы с диском в одном из массивов (io error, pending sectors). Диск был заменён, начался ребилд.
(всё это время клиентов обслуживала оставшаяся половинка)
Узел был введён в кластер, но без обслуживания клиентов (в secondary режиме).
Примерно в 11, после перехода drbd в UpToDate/UpToDate режима, оставшийся (необновлённый и планируемый к обновлению) узел показал тот самый трейс, который и планировалось устранить.
Обслуживание клиентов переключилось на вторую половинку (обновлённую).
В 11:15 мы столкнулись с багом (описание ниже), который, как выяснилось, был отличен от бага с падением машины, который привёл к прекращению работы raid10 на первой половинке кластера. Вторая половинка кластера в этот момент начала checking после перезагрузки (о проблемах от этого — в описании бага).
Для решения проблемы пришлось перезагрузить хранилища, дождаться завершения rebuild/checking (самая долгая часть) и скинуть содержимое кеша (raid на SSD) на диски. После этого (примерно 16:10) начался запуск машин. К 16:30 запуск закончился. По нашим данным (за вычетом даунтайма) повреждений данных у машин не было, запустилось и работает 100% из них (возможно кому-то надо будет на консоли согласиться с запуском fsck).
Теперь главное — что за баг?
к сожалению, воспроизвести его в лаборатории нам не удалось (сейчас мы полностью воссоздаём весь стек устройств и точную конфигурацию и будем её мучить, чтобы достоверно поймать проблему).
Симптомы:
При запуске любых асинхронных операций mdadm (checking, resync) и наличии нагрузки raid10 прекращает обслуживать запросы. Это выглядит следующим образом:
dd if=/dev/md2 of=/dev/null bs=512 count=1 iflag=direct
просто не завершается.
Ровно так же не завершаются все остальные запросы (от iscsi target и других компонент). Все диски, из которых состоит raid10 прекрасно работают и не показывают снижения скорости.
Я не могу сейчас сказать условия возникновения этой проблемы, но точно могу сказать, что она воспроизводится гарантированно.
В настоящий момент мы запретили любые самостоятельные операции raid10, подняли оба узла.
Косвенной причиной сбоя стали профилактические работы, настоящей — неожиданная ошибка в работе raid10 (вместо того, чтобы из нескольких ненадёжных дисков сделать надёжный массив, он из нескольких надёжных дисков сделал шути-что).
Наши меры: воспроизведение ошибки в лаборатории, изучение условий возникновения, поиск решения. В течение этого времени — сохранение статуса кво без каких-либо манипуляций над СХД, которые могут привести к запуску проверки массивов.
Дальнейшие меры — если нам удастся локализовать и исправить ошибку, исправить её. Если нет — поиск альтернативных решений.
Компенсация за простой машин будет предоставлена на следующей неделе.
Пока неясно — оно аффектит на уровне mdadm или из-за iscsi?
raid10 используется как PV для LVM, потом там в перемешку drbd, flashcache… До iscsi там как до луны. Проблема фокусируется на уровне (названия условные):
md2 sda[1], sdb[2], sdc[3], sdd[4]
md2 — не принимает и не отправляет запросы.
sda, sdb, sdc, sdd, по-очереди и одновременно (это я ещё в прошлый раз проверил) работают с нормальной соростью.
Интригу добавляет то, что у raid10 НЕТ queue. Другими словами, это не «застряло в очереди», это «застряло на этапе определения куда передать» или «этапе передачи».
md2 sda[1], sdb[2], sdc[3], sdd[4]
md2 — не принимает и не отправляет запросы.
sda, sdb, sdc, sdd, по-очереди и одновременно (это я ещё в прошлый раз проверил) работают с нормальной соростью.
Интригу добавляет то, что у raid10 НЕТ queue. Другими словами, это не «застряло в очереди», это «застряло на этапе определения куда передать» или «этапе передачи».
Ок, попробуем у себя воспроизвести. По крайней мере если это в mdadm или pv, то точно нас аффектит. Благо, пока на 3.0 остались.
Ужас в том, что второй баг воспроизвёлся именно на 3.0. И это вопроизводилось достаточно много раз, чтобы говорить про совершенно точный сценарий.
Прошлый раз я поднял всё с 5ой попытки (пока разбирался что это такое), в этот — с первой. И теперь я на 100% уверен в условиях вопроизведения (resync + activity). Другое дело, что я не знаю, какие именно моменты конфигурации к этому приводят…
И баг с падением ядра был так точно воспроизводим, что мы (я) поверили, что это «он и есть». А баг совсем другой (dd + hdparm), и он не проявлялся на 3.0, что сегодня утром у меня не было сомнений в методе решения…
Прошлый раз я поднял всё с 5ой попытки (пока разбирался что это такое), в этот — с первой. И теперь я на 100% уверен в условиях вопроизведения (resync + activity). Другое дело, что я не знаю, какие именно моменты конфигурации к этому приводят…
И баг с падением ядра был так точно воспроизводим, что мы (я) поверили, что это «он и есть». А баг совсем другой (dd + hdparm), и он не проявлялся на 3.0, что сегодня утром у меня не было сомнений в методе решения…
Неужели разработчики ядра Linux не стресс-тестируют свои решения на отладочных подсистемах, имитирующих разнообразные сбои? Вопрос риторический. Но все-таки. Тема интересная, уж извините.
Ваша конфигурация не уникальная, а более-менее типична, как понимаю.
Отчего им (разработчикам) не собрать стенд, на котором стоит «поддельный диск», который постоянно имитирует разные ошибки ввода/вывода?
Ведь, очевидно, что, если они проверяют свои системы ввода/вывода в «обычных» условиях, то есть, грубо говоря, без интенсивной имитации сбоев, то это все равно, что и не проверять их вовсе. Это все равно что проверять программы архивации, отключив сжатие.
Сделали какую-то оптимизацию. Запустили — вроде работает. _Пока нет ошибок ввода-вывода_.
Знаю, что разработчики SQLITE используют специальную тестовую файловую систему, которая имитирует всевозможные сбои. И (гордо) заверяют, что тесты настолько жестокие, что позволяют им гарантировать, что данные не будут потеряны.
Это не наезд, и уж тем более не на вас. Может кто-то знающий прояснит ситуацию.
ЗЫ Речь, кстати, о ядре linux? Я не ошибся?
Ваша конфигурация не уникальная, а более-менее типична, как понимаю.
Отчего им (разработчикам) не собрать стенд, на котором стоит «поддельный диск», который постоянно имитирует разные ошибки ввода/вывода?
Ведь, очевидно, что, если они проверяют свои системы ввода/вывода в «обычных» условиях, то есть, грубо говоря, без интенсивной имитации сбоев, то это все равно, что и не проверять их вовсе. Это все равно что проверять программы архивации, отключив сжатие.
Сделали какую-то оптимизацию. Запустили — вроде работает. _Пока нет ошибок ввода-вывода_.
Знаю, что разработчики SQLITE используют специальную тестовую файловую систему, которая имитирует всевозможные сбои. И (гордо) заверяют, что тесты настолько жестокие, что позволяют им гарантировать, что данные не будут потеряны.
Это не наезд, и уж тем более не на вас. Может кто-то знающий прояснит ситуацию.
ЗЫ Речь, кстати, о ядре linux? Я не ошибся?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Очередная авария у Selectel