Vendors That Provide POSIX Filesystem Interfaces Over S3-Compatible Object Storage

Mounting S3, GCS, Azure Blob, and other object stores as one unified filesystem is possible today, but only because vendors stopped trying to patch the problem at the client and started rebuilding it at the storage layer. The underlying issue is a mismatch of promises. POSIX guarantees atomic rename, in-place byte-level writes, hard links, symbolic links, and file locking through flock and fcntl, all enforced at the system-call level. S3 makes none of those promises. S3 offers full-object PUT and GET, with no native rename, no byte-range writes, and a flat namespace of keys in place of a directory tree.

That mismatch has a concrete cost. A rename on S3 is really a copy followed by a delete, and the gap between those two steps is where correctness bugs live. That gap is the whole reason table formats like Apache Iceberg, Delta Lake, and Apache Hudi exist: they bolt ACID transactions, schema evolution, and reliable metadata management onto data lakes that were never built to support any of it natively. Training checkpoints hit the same wall from a different angle. PyTorch's standard atomic-write pattern writes to a temp file, then renames it to the final filename. On a real filesystem, that rename is instant and atomic. On S3, it silently breaks, because there's no such thing as an atomic rename to fall back on.

The 2010s tried to solve this with client-side translation layers, and the results make the limits of that approach clear. S3FS-FUSE translated POSIX calls into S3 API operations. It worked fine for one person browsing files, but it fell apart under production load. Goofys dropped most of the metadata emulation to go faster, but it couldn't guarantee consistency when multiple writers touched the same data, and it turned every small write into a full-object PUT, a classic case of write amplification. Both tools shared the same three structural flaws: a consistency gap from S3's pre-2020 eventual-consistency model, the cost of emulating metadata one API call at a time, and write amplification baked into the architecture. None of those three flaws can be fixed by writing cleverer client code. The storage service itself had to change.

What Changed on the S3 Side Between 2020 and 2026

S3 saw three platform-level shifts, and they explain why solutions built after 2020 succeed where S3FS-FUSE and Goofys failed. The first was strong consistency, which AWS added to S3 in December 2020. Before that change, a read immediately after a write could return stale data, a real corruption risk for any workload that depends on recovering a training checkpoint exactly as it was saved. Strong consistency isn't a nice-to-have for filesystem semantics; it's the floor.

The second shift was S3 Express One Zone, rolled out in 2023 and 2024, which cut first-byte latency from hundreds of milliseconds down to single digits and substantially raised how many requests the service could handle. Alongside it came directory buckets, giving S3 a namespace that behaves like an actual filesystem prefix. The third shift, native directory semantics introduced in 2023, mattered because S3's original design had no concept of a directory at all, only key prefixes. FUSE clients had to enumerate those prefixes to fake an ls command, and that meant an expensive LIST round-trip on every pass. Removing that tax is what made prefix-based filesystem emulation viable at any real scale.

Put together, these changes mean the fix for POSIX-over-S3 arrived on the server side of the equation, not the client side. Every vendor covered in this guide is building on top of a storage platform that, as of a few years ago, simply couldn't have supported them.

A taxonomy of the four architectural patterns vendors use to deliver POSIX semantics over S3

Vendors solving this problem differ in where they put the logic that enforces POSIX rules, and that one design decision shapes which workloads each one can actually serve. Four broad patterns cover the field, plus a fifth that's really a variant of one of them.

Pattern one is the thin FUSE client over S3: it translates POSIX system calls into S3 API calls at the client, has the lowest operational overhead of any approach, and the shallowest semantic coverage. S3FS-FUSE and Goofys, along with their modern descendants, live here.

Pattern two is the metadata-separated architecture, which splits metadata into a fast external database while keeping bulk data in object storage. You get full POSIX semantics this way, including hard links, but you have to run an extra piece of infrastructure. JuiceFS is the clearest example.

Pattern three flips the direction entirely: instead of adding POSIX on top of S3, it exposes an already-POSIX filesystem through an S3-compatible API, with the filesystem itself remaining the source of truth. VersityGW represents this pattern.

Pattern four is server-side native POSIX over S3, delivered as a managed service, and it enforces semantics at the storage layer. Amazon S3 Files, announced April 7, 2026, is the first managed offering in this category, pairing an EFS caching tier with S3 (Standard or Express One Zone) as the durable backing store.

Pattern five is the commercial cloud-agnostic POSIX layer: a full-featured distributed filesystem backed directly by object storage, with no separate metadata server or coordination service required. ObjectiveFS and Archil both sit here. None of these five patterns is the universally correct answer. Each is a different answer to the question of where you're willing to put complexity.

JuiceFS: full POSIX semantics via a separated metadata engine, with an operational dependency to manage

JuiceFS splits metadata out of object storage entirely and puts it in a dedicated, fast database, so it gets closer to full POSIX coverage than almost anything else in the open-source world, hard links included. Data still lives in S3 or an equivalent object store, but the system that tracks what's where, what's locked, and what just got renamed runs on its own. It's licensed under Apache License 2.0.

That split is also the cost. The metadata store is a new, independent, stateful service that someone has to keep highly available, back up on its own schedule, and size correctly for the working set of metadata it holds. If a team wants POSIX semantics without taking on another database to operate, this is a real and ongoing commitment, not a footnote. Files written through JuiceFS land in object storage in JuiceFS's own block format, not as ordinary, recognizable files, a second wrinkle worth knowing before committing. So you get no casual rsync, no poking around with a text editor, no pulling data back out of the bucket without going through JuiceFS itself. If a team treats the raw bucket as a recovery option of last resort, this is a meaningful constraint.

VersityGW: exposing an existing POSIX filesystem through an S3-compatible API, leaving files as ordinary files

VersityGW solves a different problem than JuiceFS solves. Rather than adding POSIX behavior on top of object storage, VersityGW takes a filesystem that's already POSIX, something sitting on disk right now, and it puts an S3-compatible API in front of it. Nothing about the files underneath changes. They stay ordinary files, inspectable, rsync-able, recoverable with nothing more than standard filesystem tools, gateway software or not. It's licensed under Apache 2.0 and supports a range of backends: POSIX filesystems, ScoutFS, Azure Blob Storage, other S3-compatible services, and custom backends built for specific needs.

The limitation follows directly from the design. VersityGW doesn't manufacture POSIX guarantees out of nothing. It exposes whatever guarantees the underlying filesystem already had, no more and no less. If that filesystem is solid, the gateway is solid. If it isn't, the gateway won't rescue it. That makes VersityGW the right fit for a specific kind of team: one that already runs a POSIX filesystem and needs an S3-shaped front door on it, or one that treats the ability to recover files without the gateway software as a hard requirement.

ObjectiveFS: distributed POSIX over object storage with no external metadata server

ObjectiveFS takes the goal of pattern two, full distributed POSIX semantics, and removes the operational weight that came with it. There's no separate metadata server, no coordination service, no storage cluster to stand up alongside it. The object store is the only backend ObjectiveFS needs. It runs as a log-structured filesystem that uses the object store itself for persistent storage, so it doesn't ship metadata off to a dedicated database the way JuiceFS does.

In practice, that means the requirement list is short: ObjectiveFS running on the relevant servers, plus an object store such as Amazon S3, and nothing else. That makes it a strong match for existing applications that simply need to run in the cloud against a standard filesystem interface, unmodified. The trade-off against JuiceFS is proportional rather than severe: lower operational overhead, since there's no metadata store to babysit, but workloads that are extremely metadata-heavy, lots of small files, lots of directory listings, may see higher latency, since metadata operations are going to object storage rather than a store built and tuned specifically for speed. For most workloads that aren't metadata-dominated, that distinction won't be the deciding factor.

Amazon S3 Files: the first managed service to enforce POSIX semantics at the storage layer rather than the client

Amazon S3 Files, announced April 7, 2026, changes the terms of this whole comparison for any team already running on AWS. It's the first managed service to deliver native POSIX semantics enforced at the storage layer, rather than faked at the client the way S3FS-FUSE and Goofys always had to. The distinction matters technically: the enforcement happens in the EFS caching tier sitting in front of S3, not in raw S3 itself, which still has none of these semantics on its own. S3 Files combines that EFS tier with S3, either Standard or Express One Zone, as the durable backing store underneath.

The protocol choice is NFS v4.1/v4.2. Existing training infrastructure, PyTorch's torchrun, Horovod, Ray, connects without any code changes. That's the practical payoff of moving enforcement to the server: POSIX semantics stop being something a client library approximates and become something the service itself guarantees. The constraint is equally plain. This is a managed service inside AWS, so any team running multi-cloud, or sitting on object storage outside AWS, can't use it directly. But for AWS-native workloads, the April 2026 announcement closes out a decade of client-side workarounds with something that actually works at the layer where the problem lives.

DDN EXAScaler and Infinia: parallel filesystem and object platform for the largest GPU clusters

At the largest scale of GPU training, the pattern actually deployed pairs a Lustre-derived parallel filesystem with a high-performance object platform, running side by side as complementary systems. DDN operates both halves. EXAScaler, the Lustre-derived parallel filesystem, handles training. Infinia, a key-value object platform, picked up multi-tenancy and POSIX support in version 2.4 and targets inference and AI factory workloads. DDN describes the two as complementary pieces of one system, not rival products competing for the same job.

The scale involved is easiest to grasp through named deployments. xAI's Colossus cluster, announced in late 2024 with further scaling plans on the table, runs on EXAScaler and Infinia together. DDN operates a single Infinia cluster at xAI that it describes as the largest S3 cluster outside of AWS in a single namespace, running at a scale of hundreds of petabytes. On the enterprise side, Salesforce deployed Google Cloud Managed Lustre, powered by DDN EXAScaler, and reported faster model training, lower I/O latency, and lower training costs as a result.

Scality RING occupies an adjacent spot in this same enterprise tier. It supports an NFS v3/v4 file connector, an SMB file connector, a FUSE connector for local Linux host filesystem access, and a fully parallel POSIX-compliant filesystem running alongside a native S3 API. It's built for petabyte-to-exabyte environments with heavy concurrency, and it's positioned to give one logical view across on-premises, cloud, and edge deployments at once.

Archil: cloud-agnostic POSIX filesystem over existing buckets, with NVMe caching and serverless execution for agent workloads

Archil sits in the same commercial, cloud-agnostic POSIX category as ObjectiveFS, built around the same core idea of skipping the external metadata server entirely, but its sharpest edge is how it serves AI agents and inference workloads specifically. Archil ships full POSIX semantic coverage, atomic rename, flock and fcntl locking, hard links, symlinks, random writes, and appends, on top of an NVMe caching tier that keeps active data close to compute. Layered on top of that is serverless execution: an agent can run bash commands directly against the filesystem without a separate sandbox. Agent context can persist across sessions and across parallel runs.

The mount model is simple on purpose. Pointing Archil at an existing S3, GCS, R2, Azure Blob, or other S3-compatible bucket makes it mount as a real POSIX filesystem, with no migration step, no ETL pipeline, and no changes to application code. That's the direct answer to the question of mounting multiple cloud object stores as one filesystem without duplicating data anywhere: the bucket stays the one place the data actually lives.

Set against ObjectiveFS, both tools remove the external metadata server from the picture. Archil adds the NVMe caching layer, the built-in execution environment for agents, and explicit support for mounting buckets across all four major providers, S3, GCS, R2, and Azure Blob, the same way in each case. Set against Amazon S3 Files, the contrast is about reach rather than depth: Archil works across all four major cloud object stores and isn't locked to AWS, so a team with multi-cloud requirements gets the same interface no matter which cloud the bucket actually sits in.

The dominant trade-off: metadata dependency versus operational simplicity versus semantic completeness

Every architecture surveyed here forces a choice among three properties: how completely it covers POSIX semantics, how light its operational footprint is, and whether files stay interoperable with the raw object store underneath. No option on this list maximizes all three at once, and recognizing that is the actual starting point for picking one.

Full POSIX semantics paired with low operational overhead appears in server-side managed services like Amazon S3 Files, and in commercial cloud-agnostic layers like ObjectiveFS and Archil. The cost there is either vendor dependency or a licensing bill. Full POSIX semantics paired with open-source freedom is JuiceFS's territory, at the cost of running a separate metadata store and accepting that your data sits in object storage in a format only JuiceFS can read back. File-level interoperability, where objects stay ordinary files, combined with an S3-facing API, is VersityGW's lane, and it only works as well as the POSIX filesystem sitting underneath it. Maximum throughput for GPU-scale training belongs to enterprise parallel filesystem platforms like DDN EXAScaler and Scality RING, which demand dedicated infrastructure and real operational complexity in exchange.

Across production AI infrastructure, the pattern that keeps winning is a tiered one: a fast POSIX layer handling active computation, with S3 underneath for durable, cheap, long-term storage. Every vendor in this guide is some version of that same idea, applied with a different set of trade-offs. Critics argue that putting POSIX on top of S3 just reintroduces the latency and serialization costs object storage was built to avoid, and that frameworks should be rewritten to speak object-native APIs instead. For those systems, the tiered model is the only approach that matches how the software actually expects storage to behave.