Три скрытых бага в SPDK: как их нашли и исправили, чтобы повысить надёжность систем хранения

В основе высокопроизводительных систем хранения данных часто лежат open source-компоненты, и SPDK (Storage Performance Development Kit) — один из ключевых. Однако даже в зрелых проектах могут скрываться ошибки, которые не проявляются при штатной нагрузке. В этой статье мы расскажем о трёх таких багах, найденных и исправленных разработчиками компании «Минд Софтвэа» в рамках работы над собственной SDS-платформой uStor. Все исправления уже приняты мейнтейнерами SPDK в upstream.

Как были найдены скрытые дефекты SPDK

Первая проблема связана с обработчиком ошибок при создании тома (bdev) в SPDK. В нормальном режиме создание тома проходит успешно, и код ошибки не проверяется. Однако если по какой-то причине создание тома завершается сбоем (например, из-за нехватки ресурсов), последующая работа с некорректным указателем приводит к падению процесса. Мы обнаружили это при тестировании сценариев с искусственным ограничением ресурсов. Вторая ошибка — некорректная обработка ситуации, когда при закрытии соединения (например, при разрыве сети) остаются незавершённые операции ввода-вывода. В SPDK используется механизм колбэков, и если не дождаться завершения всех операций перед освобождением ресурсов, возникает состояние гонки, приводящее к двойному освобождению памяти. Третий баг проявился в логике работы с очередями команд: при определённой последовательности команд на создание и удаление томов происходила утечка памяти, которая накапливалась со временем.

Почему эти баги не проявлялись на штатной нагрузке?

Штатная нагрузка обычно подразумевает стабильное создание и удаление томов, корректное завершение соединений и отсутствие ошибок. Все три найденных дефекта требуют для своего воспроизведения специфических условий: ошибки при создании тома, разрыв соединения в момент выполнения операций ввода-вывода, или чередование команд в определённом порядке. В обычных тестах такие сценарии редко встречаются, поэтому баги оставались незамеченными длительное время. Разработчики «Минд Софтвэа» целенаправленно моделировали нештатные ситуации, включая эмуляцию отказов и ограничение ресурсов, что и позволило выявить проблемы.

Предыстория и контекст

SPDK — ключевой компонент для построения высокопроизводительных систем хранения. Он работает в пользовательском пространстве, обходит ядро ОС и использует поллинг вместо прерываний, что даёт огромный прирост производительности. Однако такой подход накладывает дополнительные требования к корректности кода: ошибки синхронизации и управления памятью могут быть фатальными. Компания «Минд Софтвэа» разрабатывает uStor — собственную SDS-платформу, которая конкурирует с решениями от NetApp, Dell EMC и других вендоров. Использование SPDK в uStor позволило добиться высокой производительности, но потребовало глубокого анализа кода. Найденные баги — типичные примеры ошибок, которые сложно выявить в процессе штатного тестирования, но которые могут проявиться при реальной эксплуатации в условиях пиковых нагрузок или нестандартных сценариев.

Технические подробности исправлений

Первое исправление: в коде создания тома (bdev) добавлена проверка возвращаемого значения функции spdkbdevcreate. Если создание завершилось ошибкой, теперь немедленно прекращается выполнение и возвращается код ошибки, вместо того чтобы продолжать работу с нулевым указателем. Второе исправление касается обработки закрытия соединения: в модуле TCP-транспорта SPDK теперь дожидается завершения всех незавершённых операций ввода-вывода перед освобождением ресурсов соединения. Это предотвращает состояние гонки. Третье исправление: в логике работы с очередями команд исправлена ошибка, при которой при определённой последовательности операций не освобождалась память, выделенная под структуры очередей. Теперь память корректно освобождается во всех ветвях выполнения. Все три патча прошли ревью мейнтейнеров SPDK и включены в основную ветку.

Какие риски несут эти баги для production-систем?

В production-средах, особенно при высоких нагрузках и нестабильных сетевых соединениях, эти баги могут приводить к падениям процессов SPDK, утечкам памяти и непредсказуемому поведению. Например, при массовом создании томов в условиях ограниченных ресурсов первый баг мог вызвать аварийное завершение target-процесса, что остановило бы доступ ко всем томам. Второй баг особенно опасен при частых разрывах TCP-соединений, что характерно для облачных сред с виртуализацией сети. Третий баг, накапливаясь, мог привести к исчерпанию памяти и деградации производительности. После применения исправлений эти риски устранены, что повышает надёжность систем хранения на базе SPDK.

Кого затронет и как

Эти исправления важны для всех, кто использует SPDK в production-средах, особенно для разработчиков систем хранения данных, облачных провайдеров и компаний, строящих собственные SDS-решения. Баги могли приводить к падениям процессов SPDK, утечкам памяти и непредсказуемому поведению при сбоях сети или оборудования. После применения исправлений надёжность систем хранения повышается, особенно в условиях высоких нагрузок и нештатных ситуаций. Для пользователей uStor это означает более стабильную работу продукта. В России и странах СНГ SPDK активно используется в разработках «Минд Софтвэа» и других компаний, поэтому исправления будут полезны локальному сообществу.

Что будет дальше

Компания «Минд Софтвэа» планирует продолжать активное участие в развитии SPDK: отправлять новые исправления, улучшать документацию и, возможно, добавлять новые функции. Разработчики рекомендуют всем пользователям SPDK обновиться до последней версии, содержащей эти исправления. В дальнейшем ожидается, что подобные скрытые дефекты будут выявляться быстрее благодаря улучшению тестового покрытия и внедрению fuzzing-тестирования в проекте SPDK.

Итог

Три исправления, отправленные в upstream SPDK, устраняют серьёзные, но редко проявляющиеся баги. Они повышают стабильность и надёжность систем хранения, построенных на SPDK. История показывает, что даже в зрелых open source-проектах могут скрываться ошибки, которые обнаруживаются только при нестандартных сценариях. Возврат исправлений в upstream — это вклад в сообщество, который окупается для всех пользователей.