Mounting Object Storage as a Filesystem

Object storage runs the world's unstructured data now, and mounting it as a filesystem is the trick that lets ordinary software pretend nothing changed. Every bucket becomes a folder, every object becomes a file, and a training script never has to know the difference. That bridge comes with real tradeoffs, and picking the wrong tool shows up fast, usually at 2 a.m., usually as a stalled GPU cluster burning money while it waits for data that's stuck one API call away.

The market backing this is huge and still growing, and most large companies already run on it. The pitch is simple: near-infinite scale, pay only for bytes stored, durability handled by the provider, no capacity planning meetings. Almost nothing outside a handful of cloud-native tools speaks S3 as a first language, though. ML frameworks, ETL jobs, legacy scientific code, most things written in the last thirty years, all expect a file path and a call to open(). Rewriting that stack to speak HTTP object APIs isn't realistic for most teams, so mounting is the patch that closes the gap.

What mounting object storage actually means at the system level

Mounting takes a bucket and makes it show up as a directory, and to an application, it looks like paths, folders, and inodes, even though none of that exists natively inside object storage. The software calls the same syscalls it always has; something else underneath does the translating.

Two approaches dominate, and they pull in opposite directions. FUSE, short for Filesystem in Userspace, intercepts filesystem calls at the kernel boundary and hands them to a userspace program that turns them into S3 API requests. It's portable and fairly easy to build, but every call now hops between kernel space and userspace, and that context switch adds latency. The other route runs an NFS layer on top of the bucket: the client mounts it like any network share, and how fast that feels depends entirely on whether a caching tier sits between the NFS server and the object store.

Either way, the translation layer has to fake some things that don't actually exist. Directory listings don't exist in object storage in any real sense; they get faked by scanning for objects that share a common prefix. Files get edited in place on a normal disk; objects generally get replaced wholesale instead. Object storage tracks metadata its own way, and that doesn't map cleanly onto POSIX inode attributes. In nearly all these setups, the bucket stays the actual source of truth: the mount is a window into the data, not a copy of it. The application never finds out any of this is happening, since it just opens a path.

Where the POSIX model and the object storage model genuinely conflict

POSIX was built around assumptions object storage never agreed to. Atomic rename is the big one. The standard safe-write pattern, write to a temp file then rename it into place, depends on rename being instant and all-or-nothing. Object storage has no equivalent move across keys. Byte-range writes and appends hit the same wall, since most object stores want the whole object rewritten, not patched in place.

Hard links and symlinks don't survive the trip either, since they're a directory-tree concept, and object storage's keyspace is flat, so there's no tree for them to hang off of. File locking, flock, fcntl, the stuff that lets two processes coordinate access to the same file, has no native equivalent. Renaming a directory, which sounds trivial on a laptop, means rewriting every single key under that prefix in a flat keyspace, and that's slow and non-atomic. It's a batch job wearing a mv costume.

Consistency used to be the sharper problem, and it's mostly settled now. S3 ran on eventual consistency for years before eventually moving to strong read-after-write consistency, though not every backend or mounting tool handles this the same way even today, so check before assuming. Latency is the one that never went away, and it's the one that actually matters: object storage API calls carry per-request overhead, commonly cited around 10 to 30 milliseconds, according to JuiceFS documentation. That number barely registers on a sequential read of a 50 GB file. It becomes brutal the moment a workload touches thousands of small files a second, because now every single one of those files is paying the toll on the way in.

None of this rules mounting out, but it does filter what mounting is good for. A training job scanning through large sequential shards doesn't care that atomic rename doesn't exist. A relational database cares enormously, and pretending otherwise is how someone ends up debugging silent corruption at midnight instead of sleeping. Pick the tool based on whether the access pattern matches what the mount can actually deliver, not on what the vendor page promises.

The AI training workload that made this problem urgent

Global AI infrastructure spending is climbing fast, and storage and networking spend is rising almost as quickly as compute spend. Yet more than half of organizations say data and storage bottlenecks are actively limiting AI performance right now. The compute is there, but the data isn't getting to it fast enough, and that gap is the entire subject of this piece.

Meta found that 56% of GPU cycles sat idle, simply waiting on training data to show up. That number makes the whole argument by itself: a cluster of expensive GPUs sitting there doing nothing because the storage layer can't feed them isn't a rounding error. It's money burning quietly in the background while a dashboard somewhere insists that training is in progress.

Object storage is where this data lives because there's no real alternative at this scale. Petabyte datasets don't fit on local NVMe drives, and block storage gets expensive fast once a dataset crosses into that territory. EBS gp3 runs about $0.08 per GB per month; S3 runs about $0.023. On a 5 TB dataset, that's roughly $400 a month on EBS versus $115 on S3. Multiply that gap across a few petabytes, and the decision makes itself; nobody needs a committee meeting to pick the cheaper option at that scale. The training loop, meanwhile, still wants a plain file path, and mounting is what reconciles the two sides. The alternative, building a custom pipeline to physically move data before training starts, just trades one problem (storage semantics) for another (pipeline engineering, plus a wait before anything can run at all).

How the main tools approach the mounting problem differently

The tools in this space aren't interchangeable, and treating them like a checklist of features misses the point entirely. Each one made a deliberate architectural bet, and that single bet explains its whole performance profile.

Mountpoint for S3, AWS's open source FUSE client, keeps things thin. It translates file calls straight into S3 requests with no caching tier in between. That makes it fast for high-throughput sequential reads, the kind common in data lake queries and ML training ingestion. In exchange, it skips in-place edits, directory renames, and symlinks on purpose. AWS built a narrow, fast tool here, not a general-purpose one, and every single read still hits S3 directly, with nothing cached locally between calls.

Amazon S3 Files, launched in 2025, takes the opposite bet, and it's the better default for anyone doing serious ML work on AWS. It's a managed NFS 4.2 layer backed by EFS storage sitting on top of the bucket, which gives it the caching tier Mountpoint lacks entirely. The benchmark gap is stark: 5 times faster on cached reads, 20 times faster on small file operations, plus functional write support in places Mountpoint simply can't go. It reached availability across all commercial AWS regions in April 2026, and it fits ML training, AI agents, and shared dev environments well. One catch worth flagging: AWS-only, with no portability to GCS, Azure Blob, or Cloudflare R2.

s3fs-fuse is the old reliable, and "reliable" is doing some generous lifting there. General-purpose, FUSE-based, no caching, fine for low-stakes work where setup speed matters more than throughput. Worth flagging: s3fs-fuse reportedly refused to install cleanly on Amazon Linux 2023, which says something about where the project sits on the maintenance spectrum these days. Like Mountpoint, it hits S3 on every read, so small files and random access sting just as much.

Object Mount, from Storj, targets near-native POSIX behavior across Linux, Windows, and macOS, aimed at media professionals and enterprise users who want the mounted drive to feel like an actual local drive instead of a clever illusion. Storj's own benchmarks show up to 7 times better performance than Mountpoint in Linux and serverless environments.

Managed NFS-over-S3 layers round out the field, and they're the right call whenever a team refuses to get locked into one cloud. These sit an NVMe caching tier between compute and the bucket, giving sub-millisecond reads on cache hits and asynchronous flush-to-bucket on writes. They support full POSIX semantics, atomic rename, locking, hard links, symlinks, sparse files, so existing code runs unmodified. Typical defaults land around 10 Gbps throughput and 10,000 IOPS per filesystem, with higher tiers available. The bigger draw for some teams: they mount the same way across S3, GCS, Azure Blob, and R2, so switching cloud providers doesn't mean rebuilding the storage layer from the ground up.

What caching architecture determines about real-world performance

Almost the entire benchmark gap between S3 Files and Mountpoint, that 5x and 20x difference, comes down to one design choice: is there a cache between the filesystem and the object store, or isn't there? That single yes-or-no answer predicts more about real-world speed than anything else on a spec sheet.

No-cache tools like Mountpoint and s3fs-fuse turn every read into an API call. Latency is bounded by the round-trip to S3, which is fine for one long sequential read and painful for anything small or repeated. Managed cache tiers, like the EFS backing behind S3 Files or dedicated NVMe caching layers, let hot data skip the object store entirely, and that's exactly where the sub-millisecond reads come from. Distributed caching, spread across compute nodes instead of centralized in one place, cuts object storage API calls by a wide margin and shines when many workers hammer the same dataset at once.

Cache hit rate isn't really about cache size; it's about access pattern, full stop. A one-time scan across a 10 TB dataset is always going to miss the cache, since there's nothing to have cached yet on the first pass. A training run doing repeated epochs over the same 500 GB subset hits the cache consistently after that first pass clears. Most teams under-budget for this distinction, then wonder why their "cached" setup still feels slow on day one.

Cost is the other half of the picture. High-performance parallel filesystems like AWS FSx for Lustre run around $0.145 per GB per month on SSD-backed storage, well above S3's $0.023. The business case for a caching tier sits exactly in that gap: keep the bulk of the data sitting cheap in object storage, and only pay premium performance costs for the slice that's actually hot right now. For bursty or agent-driven workloads, a cache billed on active use rather than provisioned capacity avoids paying for idle headroom nobody's touching.

Which workloads are genuinely good fits and which are not

Some workloads were basically built for this setup. ML training and inference lean on large files and repeated, sequential reads over the same dataset across many runs, exactly the pattern caching tiers exist to serve, and the cost math against block storage only gets better at scale. AI agent workloads need persistent, shared context across sessions, and a mounted filesystem gives an agent a stable place to read, write, and execute without rebuilding its environment every time it wakes up. Data lake analytics, heavy on reads, heavy on large files, light on strict POSIX needs, runs fine on tools like Mountpoint without needing full semantic support behind it. Media workflows, large sequential video reads and writes across platforms, fit Object Mount's design intent directly. Shared development environments, where a team needs common access to a dataset without copying it to five separate laptops, fit this model too.

Then there's the list of things that shouldn't go near this setup, full stop. Relational databases need atomic rename, real file locking, and fsync guarantees that most mounting tools either fake unreliably or skip outright; don't run production Postgres on a FUSE mount and expect to sleep well that night. High-frequency small-file writes run straight into that 10 to 30 millisecond per-object overhead, and a workload generating thousands of tiny files a second bottlenecks at the storage layer no matter how fast the compute behind it is. Anything relying on write-temp-then-rename for safety is standing on shaky ground across most FUSE implementations. Any application whose correctness depends on POSIX locking needs its specific tool checked in detail before it goes anywhere near production, not after something breaks.

The pattern across all of it: mounting object storage doesn't erase the difference between a bucket and a filesystem. It papers over that difference, skillfully in some tools, thinly in others. Knowing which is which, before the GPU cluster stalls and not after, is the entire job.