Прямой доступ к диску из python (simhdd)12.01.2017 16:48

На этот раз я расскажу о создании приложения для тестирования жестких дисков на базе этой библиотеки.

Мне нужно было приложение, которое можно запустить на сервере с hot-swap корзиной и тестировать на нем диски, заменяя их по мере прохождения тестов. Лучшим решением для этого мне показалось запускать процесс тестирования каждого диска в отдельном потоке. Поскольку опыта многопоточного программирование в python у меня не было, я начал изучать вопрос. Для создания многопоточных приложений в питоне есть модуль threading. Поскольку потоки создаются в пределах одного процесса, нет никакой проблемы с доступом к общим данным. Все выглядит очень просто. К сожалению меня поджидала проблема. Моя библиотека отказалась работать в режиме многопоточности. Значит путь мой лежал к написанию приложения с несколькими процессами и всеми прелестями межпроцессного взаимодействия. В питоне для этого есть модуль multiprocessing.

Архитектура приложения мне виделась следующим образом: Основной поток занимается взаимодействием с пользователем. Выводит список дисков, принимает команды и отображает прогресс тестов. Каждая команда диску запускается в отдельном процессе. Чтобы быть уверенным, что тест выполнится именно на том диске, на который отдавалась команда в меню, (диски например можно случайно переставить местами и забыть перечитать в программе) ключом для выполнения команды сделан серийный номер диска. Перед выполнением команды проверяется соответствие серийного номера переданного команде при запуске, серийному номеру подключенного диска. При несовпадении номеров команда отклоняется со звуковым сигналом. Полезная функция, чтобы случайно не запустить деструктивный тест на диске, подключенном чтобы посмотреть SMART.

Для обмена данными между основным процессом и процессами тестирования было создано несколько словарей. Ключами словарей являются серийные номера дисков. Мне не очень нравится решение в виде пачки словарей, но лучшего я пока не придумал.

Вот, как выглядит главное окно программы.

Каждый диск в программе имеет режим, в котором он находится. По умолчанию это режим простоя «idle». При запуске теста этот режим изменяется на название выполняемого теста. Процесс теста регулярно проверяет соответствие режима своему названию, а при несовпадении прерывает тест. Таким образом основной процесс может прервать выполнение теста поменяв диску режим на idle. Программа может запускать на дисках встроенные SMART-тесты (Short и Extended), проверять диски последовательным чтением и записью. При этом тест записи сделан цикличным, прописывающим диск снова и снова, отмечая сколько циклов было сделано. Непрерывная циклическая запись позволяет «добить» диски у которых «сыпется» поверхность, но которые еще не набрали нужное количество ошибок для возврата поставщику. За несколько дней в таком режиме они обычно доходят до состояния SMART status bad, что является основанием для замены. На экране, при тестировании показывается скорость прохождения теста (где это возможно), количество ошибок диска и количество «медленных» секторов. Время, после которого сектор считается «медленным» задается константой в программе. Программа также умеет показывать основную информацию по диску, SMART и логи SMART-тестов.

Тест записи может прописывать диск как нулевыми значениями так и уникальным партерном, по которому можно будет определить, что диск уже тестировался этой программой. Метод записи переключается тоже константой. Поскольку программа рассчитывалась на загрузку тестовой среды по сети, в ней есть возможность отключить в меню пункт выхода из программы.

Вот такая получилась утилитка, может кому нибудь пригодится. Код утилиты и библиотеки, на которой она построена доступен на github.

Комментарии (1)

• amarao

  12 января 2017 в 15:31

  0

  ↑

  ↓

  Когда я разрабатывал in-house программу для замены дисков (с пересозданием файловых систем и т.д.) для swift-storage, одна из проблем, с которой я столкнулся, были «умирающие IO». Это когда дисковый запрос уходит, а ответа не приходит. Приложение в D+, убить нельзя, ничего сделать нельзя.

  В рамках попыток сделать жизнь людей лучше (вылечить эту проблему нельзя) я реализовал декоратор, который позволяет запускать код в отдельном треде, ждёт завершения или таймаута и сообщает о таймауте. Залипший тред остаётся висеть в ОС навсегда, но, хотя бы, пользователю об этом сообщают.

  https://github.com/amarao/thread_timeout