Файловая система DAXFS: оперативная память без страничного кэша и лишних копий
------------------------------------------------------------
В ядре Linux предложена новая экспериментальная файловая система DAXFS, ориентированная на использование оперативной памяти, но построенная принципиально иначе, чем привычные ramfs и tmpfs. Автор разработки — Конг Ванг, сопровождающий подсистему Traffic Control и участвующий в проекте Multikernel. Код ядра с реализацией DAXFS и утилита для создания образов mkdaxfs распространяются под лицензией GPLv2; после прохождения ревью рассматривается включение в основное дерево ядра.
Что такое DAXFS и чем она отличается от ramfs и tmpfs
По назначению DAXFS напоминает сильно урезанные ramfs и tmpfs: данные хранятся в RAM, файловая система работает в режиме «только чтение», а её содержимое заранее подготавливается в виде образа. Однако ключевое отличие — использование подсистемы DAX (Direct Access) и принципиальный обход страничного кэша ядра.
В ramfs и tmpfs данные фактически лежат в страничном кэше, а обращение к ним идёт через обычный путь файлового ввода‑вывода. Это означает:
- при использовании одной и той же ФС несколькими контейнерами или разными ядрами (в сценариях Multikernel) в физической памяти возникают дубликаты одних и тех же страниц;
- наполнение файловой системы требует копирования данных в кэш, без возможности напрямую промапить уже существующую область памяти.
DAXFS устраняет оба этих недостатка.
DAX и обход страничного кэша
Подсистема DAX позволяет приложениям и подсистемам ядра работать с памятью напрямую, минуя страничный кэш и классический стек ввода‑вывода, завязанный на блочные устройства и буферизацию. В случае DAXFS это означает:
- доступ к содержимому файлов идёт как к непрерывным участкам физической памяти;
- исключаются лишние копирования (режим Zero-Copy): то, что находится в памяти, и есть содержимое файла, без дополнительного дублирования в кэше;
- уменьшается фрагментация и перерасход RAM при совместном использовании одной и той же ФС несколькими контейнерами или ядрами в архитектурах типа Multikernel.
DAXFS позволяет маппировать заранее выделенные и непрерывные области физической памяти в каждый экземпляр контейнера или ядра, обеспечивая им общий доступ к одному набору данных без копирования.
Поддержка dma-buf и аппаратных ускорителей
Ещё одно важное свойство DAXFS — возможность использовать API dma-buf. Это даёт доступ к памяти, экспортируемой различными устройствами:
- графическими процессорами (GPU),
- FPGA и SmartNIC,
- устройствами на базе шины CXL (Compute Express Link) и другой постоянной или разделяемой памятью.
Файловая система превращается в удобный механизм предоставления единого адресного пространства для данных, с которыми работают как CPU, так и ускорители, при этом взаимодействие происходит без традиционного сетевого или блочного ввода‑вывода и без промежуточных копий.
Почему DAXFS только для чтения и как она инициализируется
DAXFS работает строго в режиме read‑only. Она не занимается динамическим выделением памяти в рантайме и не содержит сложных механизмов журналирования, записи и управления устройствами. Вместо этого:
- заранее формируется образ файловой системы;
- при инициализации он загружается в память как непрерывный регион;
- поверх этого региона монтируется DAXFS, которая предоставляет файлы и каталоги как неизменяемый набор данных.
Такой подход радикально упрощает реализацию, убирает накладные расходы на управление памятью и повышает предсказуемость поведения, что особенно важно в системах реального времени, высоконагруженных кластерах и мультикернельных конфигурациях.
Логичный вопрос: как сохранять результаты вычислений?
Ограничение «только чтение» вызывает закономерный вопрос: если в RAM через DAXFS загружаются исполняемые файлы, библиотеки или базовые данные, где хранить результаты работы, логи и изменяемое состояние?
Типичный ответ архитектурный, а не «обходной»:
- DAXFS используется как статичный корневой или базовый образ с кодом и неизменяемыми ресурсами;
- для данных, которые нужно менять и сохранять, применяются другие ФС — на классическом блочном устройстве, tmpfs, ramfs или специализированных дисковых ФС;
- приложение может иметь корень системы на DAXFS, а каталоги вроде `/var`, `/tmp`, пользовательские домашние директории или рабочие директории — на отдельных разделе(ах), где запись разрешена.
В результате DAXFS берёт на себя роль сверхбыстрого, экономного по памяти и общедоступного носителя «золотого» образа (бинарники, конфигурации по умолчанию, статические ресурсы), а изменяемое состояние уходит в обычные файловые системы или в специально выделенную память.
Для высокопроизводительных сценариев можно комбинировать:
- чтение входных данных из DAXFS;
- обмен промежуточными результатами через mmap, общую память или dma-buf;
- конечную запись на дисковую ФС только тех артефактов, которые действительно нужно сохранить.
Связка с Multikernel и контейнерами
Основная целевая область применения DAXFS — совместная работа с технологией Multikernel. Эта архитектура позволяет запускать на одном физическом сервере несколько независимых ядер Linux, каждое из которых:
- имеет прямой доступ к части аппаратных ресурсов;
- может быть сконфигурировано под свои задачи и политику безопасности;
- остаётся изолированным от других ядер.
DAXFS в таком окружении служит общим, разделяемым базовым образом для всех этих ядер. Вместо того чтобы каждое ядро держало отдельную копию тех же самых библиотек и файлов в собственном страничном кэше, все они читают один и тот же участок RAM, маппированный через DAX. Это сокращает расход памяти, снижает фрагментацию и улучшает кэш‑локальность.
Аналогичный сценарий возможен и для контейнеров: один неизменяемый образ с бинарниками и библиотеками может быть общим для десятков контейнеров, при этом:
- не появляется дубликатов страниц в RAM;
- проще обеспечивать консистентность версий ПО;
- упрощается безопасное обновление: новый образ готовится отдельно и по необходимости подменяется.
Другие потенциальные сценарии использования
Помимо Multikernel, DAXFS может использоваться и в других случаях:
- предоставление базового системного образа для множества контейнеров, виртуальных машин или лёгких изолированных окружений;
- доступ нескольких хостов к общей памяти без использования сетевого стека, когда предусмотрены соответствующие аппаратные средства;
- работы с постоянной памятью на базе CXL‑устройств, где нужна минимальная задержка и прямая адресация;
- уменьшение накладных расходов при доступе к памяти аппаратных ускорителей, когда данные должны быть доступны как CPU, так и GPU/FPGA без копирования.
Почему подобные проекты не всегда остаются в ядре
История Linux знает немало примеров, когда перспективные или популярные на момент создания файловые системы со временем выводились из основного дерева. Часто причина не только в технических недостатках, но и в отсутствии долгосрочной поддержки.
Характерный пример — ReiserFS: в своё время это была заметная альтернативная ФС, однако развитие проекта застопорилось, ключевой разработчик оказался недоступен, а у сообщества не нашлось устойчивой команды, готовой взять на себя полную поддержку и развитие кода. В итоге файловая система постепенно признана устаревшей и выведена из ядра.
Для включения любых новых подсистем и ФС важно не только их техническое качество и производительность, но и наличие понятной модели сопровождения: кто будет исправлять ошибки, адаптировать код под изменения в ядре, реагировать на отчёты пользователей и развивать функциональность. Нередко крупные компании становятся гарантами такой поддержки, поскольку заинтересованы в использовании технологии в своих продуктах и вкладываются в её доработку.
Реалистичный взгляд на будущее DAXFS
Для DAXFS ключевыми факторами выживаемости будут:
- наличие реальных пользователей и сценариев в индустрии (высокопроизводительные вычисления, телеком, облачные платформы, крупные кластеры);
- вовлечённость нескольких разработчиков и команд, способных поддерживать код;
- стабильный API и понятная интеграция с существующими механизмами ядра (DAX, dma-buf, управление памятью).
Если технология окажется востребованной, она может стать важным инструментом для тех, кто строит системы с упором на минимальную задержку доступа к данным, плотную упаковку контейнеров и эффективное использование аппаратных ускорителей. Если же интерес будет ограничен узкой экспериментальной областью, не исключено, что DAXFS останется нишевым решением или так и не будет включена в основную ветку.
Итоги
DAXFS — это попытка переосмыслить использование RAM в Linux как носителя файловой системы:
- данные хранятся в оперативной памяти, но без участия страничного кэша;
- реализован режим Zero-Copy и прямой доступ к физической памяти через DAX;
- поддерживается dma-buf для обмена с GPU, FPGA, SmartNIC и устройствами на CXL;
- файловая система строго read‑only и загружается из заранее подготовленного образа;
- основной сценарий — совместное использование одной базы файлов несколькими контейнерами или ядрами в архитектуре Multikernel.
Запись результатов вычислений при этом выносится на другие ФС или механизмы, а DAXFS занимает свою нишу: максимально быстрая и экономная по памяти платформа для неизменяемых данных и базовых системных образов.
