zerofs

ZeroFS - это журнально-структурированная файловая система, которая использует S3-совместимый бакет как единственное персистентное хранилище. Она отдаёт это хранилище как POSIX-файловую систему по NFS и 9P или как сырое блочное устройство по NBD, поэтому обычные приложения работают со стандартной точкой монтирования, пока байты лежат в объектном хранилище. В отличие от Amazon S3 Files, ZeroFS не хранит один файл на один S3-объект - бакет служит внутренним слоем персистентности, а не набором читаемых объектов. Сравнение лоб в лоб с S3 Files смотрите на странице zerofs-vs-s3-files.

Как это устроено

Метаданные файловой системы живут в lsm-tree. Содержимое файлов разбивается на экстенты, сжимается, шифруется и упаковывается в неизменяемые сегментные объекты. Метаданные и данные файлов идут разными путями и сходятся только в объектном хранилище, оседая в виде SST-файлов метаданных и сегментных объектов. Поскольку небольшие файлы упаковываются вместе в общие сегменты, они не требуют отдельного объекта и отдельного PUT на каждый файл - реальная проблема объектных хранилищ при миллионах мелких файлов. Бакет и локальный кэш зашифрованы, поэтому для монтирования или восстановления требуются ZeroFS и пароль шифрования; в открытом виде остаётся только часть структурных метаданных.

Перед объектным хранилищем находится локальный кэш в оперативной памяти и на диске. Он наполняется при чтениях и из свежезапечатанных сегментов, так что чтение сразу после записи не требует GET-запроса. Кэш работает без отложенной записи (write-back) - записи попадают в объектное хранилище, когда сегменты запечатываются, а метаданные сбрасываются. Холодные промахи находят экстенты через LSM-дерево и объединяют соседние фреймы в диапазонные GET-запросы с упреждающим чтением внутри сегментов и между ними для последовательного трафика.

Надёжность сохранения данных (durability) явная. По протоколу 9P успешный fsync возвращает управление только после того, как объектное хранилище подтвердило получение сегмента данных и связанных метаданных LSM, чего достаточно для sqlite (чистого NFS недостаточно). Внутри реализован подход copy-on-write с неизменяемыми сегментами и чекпоинтами. На данный момент WAL или журнал для несброшенных данных отсутствует, поэтому всё, что ещё не сброшено на диск, может потеряться при сбое. Система поддерживает только одного писателя (single-writer) без горизонтального масштабирования записи, а дедупликация и reflink'и отсутствуют (их исключили намеренно ради сохранения локальности данных).

Использование

Укажите бакет и смонтируйте:

# start ZeroFS against an S3-compatible bucket
ZEROFS_ENCRYPTION_PASSWORD=... zerofs s3://my-bucket/prefix

# then mount over NFS or 9P from the client side
mount -t nfs -o ... localhost:/ /mnt/zerofs

Поддерживаются Amazon S3, S3-совместимые хранилища (Garage, MinIO и аналогичные), Azure Blob и Google Cloud Storage. Поддержка условных PUT-запросов использует Redis/Valkey для координации; конфигурации по умолчанию достаточно. Inotify работает для изменений, сделанных через локальную точку монтирования, но не отслеживает правки других клиентов.

Тестирование и зрелость

Для молодого проекта в области хранения данных тестовая база развита необычайно глубоко. Набор детерминированных симуляций вносит сбои хранилища и падения в произвольные моменты, а затем сверяет восстановленные данные с эталонными моделями, запускаясь каждый час со свежими seed'ами. В CI дополнительно гоняются pjdfstest, xfstests, stress-ng, ZFS scrub и тесты сбоев/отказоустойчивости Jepsen.

Ограничения

Нет WAL для несброшенных данных, только один пишущий узел, нет дедупликации или reflink'ов, а поддержка NFSv4 не планируется (автор предпочитает расширения 9P). Проект разрабатывается одним автором и пока находится на ранней стадии, поэтому добавлен в watchlist - перед внедрением в проде стоит перепроверить наличие WAL, поддержку нескольких писателей и регулярность релизов.

Репозиторий: github.com/Barre/ZeroFS - ~2 880 звёзд, AGPL-3.0, Rust.