ZeroFS против Amazon S3 Files

И Amazon S3 Files, и ZeroFS монтируют файловую систему POSIX поверх S3-бакета, поэтому издалека они выглядят взаимозаменяемыми. В статье на zerofs.net (написанной автором ZeroFS) утверждается, что они дают противоположные обещания относительно содержимого бакета. S3 Files хранит каждый файл как обычный объект S3, который по-прежнему можно прочитать через GetObject. ZeroFS относится к бакету как к внутреннему слою персистентности, содержимое которого бессмысленно без самого ZeroFS и пароля шифрования. Всё остальное - стоимость, поведение при холодном чтении, накладные расходы на переименование, момент появления данных в доступе - вытекает из этого единственного различия.

Два подхода к структуре данных

S3 Files построен на базе Amazon EFS. Путь вроде images/cat.jpg в точке монтирования соответствует ключу images/cat.jpg в бакете, и изменения синхронизируются в обоих направлениях. Активные данные и метаданные находятся на уровне с низкими задержками, который AWS называет "high-performance storage", а точка монтирования работает по протоколам NFS 4.1/4.2.

ZeroFS намеренно отказывается от схемы "один файл - один объект". Метаданные файловой системы живут в lsm-tree; содержимое файлов нарезается на экстенты, сжимается, шифруется и упаковывается в неизменяемые объекты-сегменты. Метаданные и данные файлов идут разными путями и встречаются только в объектном хранилище, куда они попадают в виде SST-файлов метаданных и объектов-сегментов. S3-клиент при прямом обращении к бакету видит непрозрачные сегменты, а не файлы. ZeroFS отдаёт эту файловую систему по протоколам 9P или NFS для файлов и NBD для блочных устройств. Кроме того, в отличие от S3 Files, он не привязан к Amazon - его можно запустить на любом S3-совместимом хранилище, Azure Blob или Google Cloud Storage.

В чём расходятся архитектурные решения

Главное отличие - интероперабельность на уровне объектов. В S3 Files файл, записанный через точку монтирования, становится обычным объектом после асинхронного экспорта, который запускается через 60 секунд после последней записи. Продолжение записи откладывает видимость объекта, а если объект отредактируют одновременно со стороны S3 и со стороны файловой системы до синхронизации, побеждает версия из S3, а копия из файловой системы отправляется в lost+found. ZeroFS вообще никогда не выставляет смонтированные файлы через API S3: взамен мелкие файлы больше не требуют отдельного объекта и отдельного вызова PUT на каждый, так как их экстенты упаковываются вместе, а весь бакет целиком зашифрован при хранении.

Холодное чтение устроено по-разному. При первом обращении S3 Files к директории импортируются метаданные всех объектов и асинхронно копируются в производительное хранилище файлы меньше заданного порога (по умолчанию 128 KiB); первое чтение списка из 1000 объектов может занять несколько секунд, а запросы на чтение от 1 MiB уходят напрямую в S3. ZeroFS находит нужные экстенты через LSM-дерево и объединяет соседние фреймы в range-запросы GET, обходясь одним round-trip'ом без подтягивания остальной части файла или директории. Локальный кэш в RAM и на диске наполняется при чтении и при фиксации новых сегментов, поэтому чтение сразу после записи не требует GET. Когда рабочий набор данных помещается локально, запросы данных почти не генерируют обращений к S3.

Семантика fsync различается так, что это принципиально для баз данных. В S3 Files сохранность данных на диске (durability) и их видимость в S3 - разные события: запись в high-performance storage становится надёжной сразу, но fsync не делает объект видимым через S3 API - это произойдёт только после 60-секундного ожидания экспорта. В ZeroFS второго события видимости нет, потому что нет экспорта; по протоколу 9P успешный вызов fsync возвращает управление только после того, как объектное хранилище подтвердит приём сегмента данных и метаданных в LSM, так что файл переживёт холодный перезапуск. Именно это искал один из участников обсуждения: надёжность fsync, достаточную для SQLite, что исключает обычный NFS.

Переименование дешево с одной стороны и дорого с другой. В S3 нет директорий и нет атомарного переименования для обычных бакетов, поэтому S3 Files переименовывает путь в точке монтирования, а затем копирует каждый затронутый объект под новый ключ и удаляет старый. По оценке AWS, синхронизация 100 000 переименованных файлов занимает несколько минут, и во время переименования директории могут быть видны оба префикса. ZeroFS просто перезаписывает записи директорий в LSM: никакого копирования каждого вложенного объекта, ничего видимого внешним клиентам объектного хранилища.

Стоимость

Оба варианта оплачивают хранение и запросы к S3. S3 Files добавляет к этому расходы на уровень high-performance storage: примерно $0.30 за GB-месяц хранения, $0.03 за GB прочитанных данных, $0.06 за GB записанных, с минимальным тарифицируемым размером файла в 10 KiB и обязательным версионированием бакета. Объём данных, попадающих на этот уровень, зависит от порога импорта и окна устаревания, поэтому по одному только размеру бакета спрогнозировать счёт невозможно. Стоимость ZeroFS складывается из объектного хранилища, запросов, а также вычислительных ресурсов и дискового кэша: один сервер (или два для высокой доступности), каждому из которых требуется около 2 GB RAM сверх настроенного кэша. В приведённой в статье иллюстративной модели (хранение 10 000 GiB, однократное чтение) ZeroFS обходится примерно в $115-230/месяц плюс инфраструктура, а S3 Files - от ~$231 до ~$3530 в зависимости от того, какая доля данных остаётся резидентной и состоит из мелких файлов. Автор подчёркивает, что это лишь пример, а не общее сравнение, и отмечает, что S3 Files может оказаться выгоднее при потоковом чтении больших файлов.

Что выбрать

Лучше всего суть передаёт формулировка из самой статьи: выбирайте S3 Files, когда файлы должны оставаться обычными объектами S3 для прямого чтения другими инструментами, и выбирайте ZeroFS, когда бакет может служить закрытым внутренним субстратом, где прямой доступ приносится в жертву сжатию, плотной упаковке и шифрованию на стороне клиента. Это тот же паттерн "объектное хранилище как субстрат для POSIX", который Ursa применяет к логам Kafka - надёжность и ёмкость S3 под интерфейсом, который сам по себе не является S3. Это также практический аналог концепции виртуальной файловой системы: настоящее монтирование на уровне ядра вместо in-process VFS, но с тем же подходом - предоставить API файловой системы поверх хранилища, которое диском не является.

Интересные детали из обсуждения

Автор подтвердил, что ZeroFS не пишет WAL или журнал для несброшенных данных, поэтому всё, что ещё не было записано на диск, может пропасть при сбое - комментатор (the_duke) отметил это как пробел, который стоит закрыть. Запись пока только в один поток (single-writer), горизонтального масштабирования на запись нет. Нет дедупликации (ни пофайловой, ни блочной) и нет reflinks - от них отказались осознанно, так как они ухудшают локальность данных, хотя внутри ZeroFS работает по принципу copy-on-write с неизменяемыми сегментами и чекпоинтами. Что касается надёжности, автор ссылается на набор детерминированных симуляций, которые вставляют сбои хранилища и падения в произвольные моменты и сверяют восстановленные данные с эталонными моделями, запускаясь каждый час со случайным seed'ом; в CI также гоняются pjdfstest, xfstests, stress-ng, проверки ZFS scrub и Jepsen. Из пока не реализованных запросов: сканирование файловой системы как колоночных данных в стиле DuckDB для обучения моделей AI/ML, что текущий формат упакованных сегментов ZeroFS не позволяет делать напрямую.