Comments 20
Когда я разрабатывал in-house программу для замены дисков (с пересозданием файловых систем и т.д.) для swift-storage, одна из проблем, с которой я столкнулся, были «умирающие IO». Это когда дисковый запрос уходит, а ответа не приходит. Приложение в D+, убить нельзя, ничего сделать нельзя.
В рамках попыток сделать жизнь людей лучше (вылечить эту проблему нельзя) я реализовал декоратор, который позволяет запускать код в отдельном треде, ждёт завершения или таймаута и сообщает о таймауте. Залипший тред остаётся висеть в ОС навсегда, но, хотя бы, пользователю об этом сообщают.
https://github.com/amarao/thread_timeout
В рамках попыток сделать жизнь людей лучше (вылечить эту проблему нельзя) я реализовал декоратор, который позволяет запускать код в отдельном треде, ждёт завершения или таймаута и сообщает о таймауте. Залипший тред остаётся висеть в ОС навсегда, но, хотя бы, пользователю об этом сообщают.
https://github.com/amarao/thread_timeout
Тут подобной проблемы не будет. У sgio запроса есть таймаут, задаваемый при вызове. Если диск не ответил вовремя, то команда отвалится по таймауту. Я на это напоролся, когда делал поддержку безопасности дисков. Команда снятия пароля с диска со стиранием содержимого не возвращает управление до конца стирания. На больших дисках это много часов. Приходится сдвигать таймаут на предпологаемый срок завершения.
Эти таймауты работают, если на шине всё хорошо. Просто поверьте мне, когда SCSI контроллеру или enclosure плохо, то ни какой из таймаутов не срабатывает. На совсем. Я пробовал — висит более недели (дальше у меня терпение закончилось). По коду ядра видно, что таймаут есть, но почему-то он не срабатывает. Дальше моего Си-конфу не хватило понять почему, но это стабильное поведение на LSI как минимум с 2.6.18, и по 4.4+.
Надо будет погонять на полумертвых дисках, посмотреть результат. Может проявится.
Если есть SAS-enclosure с sata-дисками, есть довольно простой трюк: https://github.com/amarao/lsi-sata-fuckup
Команда security-erase можно сказать имитирует зависание диска. Она поднимает флаг занятости диска на очень долгое время. А следующая команда попадая в очередь блокирует ее на весь sas порт? Тогда это програмный косяк в драйверах. И все развиснет, как только закончится security-erase.
Это работает только на корзинах с экспандером или на прямом подключении тоже?
Это работает только на корзинах с экспандером или на прямом подключении тоже?
Заинтересовали вы меня этой проблемой. Дорвусь до разных корзин обязательно потестирую.
Отпишитесь, если сделаете, пожалуйста. Я с этой проблемой половину своей карьеры сталкиваюсь.
Если что, поведение можно поменять изменив queue depth для устройств. Если queue depth =1, то проблема не возникает.
На самом деле всем пофигу на secure-erase баги, это просто метод воспроизвести проблему на рабочем железе. На нерабочем железе это выглядит так: плохо умирает диск, на него уходит запрос (запросы?) и всё — ответа назад не приходит. Иногда со всех устройств бэкплейна (это уже совсем катастрофа), иногда только с одного.
Если что, поведение можно поменять изменив queue depth для устройств. Если queue depth =1, то проблема не возникает.
На самом деле всем пофигу на secure-erase баги, это просто метод воспроизвести проблему на рабочем железе. На нерабочем железе это выглядит так: плохо умирает диск, на него уходит запрос (запросы?) и всё — ответа назад не приходит. Иногда со всех устройств бэкплейна (это уже совсем катастрофа), иногда только с одного.
UFO just landed and posted this here
Прочитав заголовок, открыл статью, рассчитывая увидеть описание способов прямого доступа к диску и используемых для этого библиотек с примерами кода и объяснением, что зачем и почему в этом коде делается. Вместо этого вижу описание некоей программы, код которой доступен на гитхабе, и ничего из ожидаемого…
Sign up to leave a comment.
Прямой доступ к диску из python (simhdd)