Файловая система Btrfs в ядре Linux 7.3 показала 1566,45 балла по среднему геометрическому всех тестов против 1244,64 у стабильного Linux 7.2 – разница около 25%. Замеры опубликованы и сделаны на рабочей станции HP Z4 G6i с процессором Intel Xeon 678X и накопителем Sandisk SN8000S на 2 ТБ. Почти весь отрыв дали операции записи с прямым вводом-выводом, где вместо отката к буферизованной записи применяется промежуточный буфер IOmap. Обратный результат тоже есть: в наборе тестов MariaDB новое ядро уступает прежнему, а случайное чтение осталось на том же уровне.
Что изменили в коде Btrfs к ядру 7.3
Правки для Btrfs отправили в ядро , через три дня после выхода стабильного Linux 7.2. Полный перечень изменений выложен в запросе на слияние в списке рассылки ядра.
Главная правка касается прямого ввода-вывода. В прежних ядрах прямая запись в файлы, для которых считаются контрольные суммы, принудительно переводилась в буферизованную: программа в пространстве пользователя могла изменить содержимое своего буфера до того, как ядро закончит запись, и контрольная сумма переставала сходиться. В Linux 7.3 такой буфер копируется в промежуточный (bounce buffer) средствами подсистемы IOmap, а откат к буферизованной записи больше не нужен. Этот механизм зафиксирован и в официальной документации Btrfs. По оценке из запроса на слияние, прежний компромисс между корректностью и скоростью удерживал производительность на уровне примерно 50% теоретического максимума, а теперь достижимо около 95%.
Прямой ввод-вывод (direct I/O) – режим, при котором данные передаются между приложением и накопителем в обход страничного кэша ядра. Его выбирают программы с собственным управлением кэшем, например СУБД и гипервизоры.
Остальные изменения этого выпуска перечислены в запросе на слияние отдельными пунктами:
- вместо структуры XArray при отслеживании буферов экстентов, помеченных как inhibited, применяются локальные списки LRU – до трёх раз быстрее;
- при полном fsync пропускается поиск дыр для файлов, в которых дыр нет, зато много экстентов – до пяти раз быстрее;
- убрана лишняя задержка в один такт системного таймера (jiffy) в режиме для накопителей без флеш-памяти при нескольких задачах журналирования: задержки снизились, а пропускная способность на образцовой нагрузке выросла примерно в пять раз;
- сокращены блокировки вокруг упреждающего чтения экстентов;
- переработаны режимы выделения буферов экстентов;
- код кэша свободного пространства первой версии отключён по умолчанию в пользу версии v2, которая и так применяется по умолчанию уже несколько лет.
Экстент – непрерывная область на накопителе, отведённая под данные файла. Небольшой файл умещается в один экстент, крупный или сильно фрагментированный занимает несколько.
Конфигурация системы: HP Z4 G6i и накопитель Sandisk SN8000S
Оба ядра проверяли на рабочей станции HP Z4 G6i с процессором Intel Xeon 678X поколения Granite Rapids WS. Под Btrfs отвели отдельный накопитель Sandisk SN8000S SDEPNRG-2T00-1006 на 2 ТБ с интерфейсом PCIe 4.0 x4. Перед каждым прогоном раздел форматировали заново и монтировали со штатными параметрами, включая механизм copy-on-write. Стабильную ветку Linux 7.2 сравнивали со снимком Git ветки 7.3 от , то есть до выхода первого кандидата в релизы.
FIO: прирост только на записи с прямым вводом-выводом
В тестах FIO с движком io_uring картина разделилась по типу операции. Случайное чтение блоками 4 КБ и последовательное чтение блоками 2 МБ на обоих ядрах прошли практически вровень, причём в большинстве конфигураций чуть впереди оказалась Linux 7.2. Случайная запись уже даёт отрыв в пользу нового ядра, а при включённом прямом вводе-выводе этот отрыв становится наибольшим по всему набору. То же самое с последовательной записью блоками 2 МБ: без прямого ввода-вывода прирост умеренный, с ним – значительный.
В Phoronix связывают такой разброс именно с переходом на промежуточный буфер IOmap, поскольку заметная разница возникает только там, где задействован прямой ввод-вывод. В SQLite на 8 и 16 потоках Linux 7.3 быстрее лишь незначительно.
Dbench, ClickHouse и TigerBeetle на реальных нагрузках
В Dbench итог зависит от числа клиентов: на одном клиенте быстрее оказалась Linux 7.2, на шести и двенадцати – Linux 7.3. В ClickHouse на наборе 100M Rows Hits Dataset задержка второго прогона снизилась умеренно, хотя раздел монтировался со штатными параметрами и copy-on-write оставался включённым.
Самый крупный выигрыш среди прикладных нагрузок пришёлся на TigerBeetle – базу данных для учёта финансовых транзакций. На одном, четырёх и восьми клиентах у Linux 7.3 одновременно выше пропускная способность и ниже задержки.
MariaDB и PostgreSQL: регресс и небольшой прирост
MariaDB осталась единственным набором, где новое ядро уступает предшественнику. В сценариях oltp_read_write на одном и на 32 потоках, а также в oltp_write_only на одном потоке впереди Linux 7.2. Отыграться новому ядру удалось только в oltp_write_only на 32 потоках.
В PostgreSQL при коэффициенте масштабирования 100 и 250 или 500 клиентах в режиме чтения и записи прирост небольшой, но проявляется и в пропускной способности, и в средней задержке.
Заключение
Разница около 25% по среднему геометрическому получена на одной конфигурации: серверный процессор Intel, один быстрый NVMe-накопитель, свежеотформатированный раздел и штатные параметры монтирования. Ощутимее всего изменения скажутся на нагрузках, которые пишут в обход страничного кэша, – базах данных и виртуальных машинах с прямым вводом-выводом. На чтении разницы почти нет, а часть тестов СУБД идёт медленнее прежнего. Сравнение Btrfs с EXT4, XFS и F2FS на том же ядре в Phoronix обещают опубликовать позже; полный набор графиков доступен в исходной публикации.