One app opened a 5 GB model checkpoint from S3 in 3.1 seconds. The same app needed almost fifty minutes to read 3,515 small images from the same bucket.

Disclosure: this is a paid review. Electronic Team, who make CloudMounter, paid for it and saw the numbers after I measured them. Nothing below was changed for them.

The Problem With Mounting a Bucket

If you train models, your data and your checkpoints probably live in S3. Your editor, your notebooks and half your tools want a folder.

Mounting the bucket in Finder looks like the obvious bridge. It is also where a lot of quiet slowness comes from, because a mount hides every network round trip behind something that looks like a local disk.

So I tested one of the paid options, CloudMounter, against the free one most engineers already use, rclone. Same Mac, same network, same bytes, every file checked against its original SHA-256.

What CloudMounter Actually Is Under the Hood

The website does not say how CloudMounter mounts anything, so I opened the app bundle. The Mac App Store build (4.18) ships no FUSE driver and no kernel extension. It plugs into Apple's File Provider, the same system behind iCloud Drive.

plutil -p "/Applications/CloudMounter.app/Contents/PlugIns/MountProvider.mas.appex/Contents/Info.plist" \ | grep ExtensionPointIdentifier # "NSExtensionPointIdentifier" => "com.apple.fileprovider-nonui"

That one design choice explains every number in this article.

With File Provider, a file is a placeholder until something opens it. The first open downloads it. After that it lives on your disk, and you can pin a folder to keep it offline. So every test has two numbers: the first read and the second.

It also means the App Store build is fully sandboxed, and your keys go into the macOS keychain instead of a config file in your home folder. The version you download from the CloudMounter website is not sandboxed.

How CloudMounter and rclone mount an S3 bucket on macOS

CloudMounter plugs into the same system as iCloud Drive. rclone on macOS runs a local NFS server. That difference explains every number below.

The Benchmark Setup

One S3 bucket in eu-central-1, and a seeded data set so every tool reads identical bytes:

# make_dataset.py (excerpt): same bytes every run blob(f"{out}/large/checkpoint_5g.bin", 5 << 30, seed=1) blob(f"{out}/large/shard_1g.bin", 1 << 30, seed=2) for i in range(10000): # a small image data set blob(f"{out}/small10k/img_{i:05d}.bin", 50 * 1024, seed=1000 + i)

On top of that, a tree of 20 folders with 500 files each. For a ceiling, I uploaded everything with the AWS CLI first: about 49 MB/s for big files and 95 small files per second, with its default of 10 concurrent requests.

For rclone I used the Homebrew build. On macOS it has no FUSE mount, and Homebrew says so at install time, so the mount goes through the built-in NFS client instead:

rclone nfsmount cmbench:my-bucket ~/cm-mnt/rclone \ --vfs-cache-mode full # run 1: defaults # run 2: same command plus --use-server-modtime

CloudMounter ran on its defaults. Everything here measures reads, because that is the work a mounted bucket does most in ML: loading checkpoints and walking datasets.

Big Files: Close to Line Speed, Then Instant

A cold read of the 5 GB checkpoint took CloudMounter 2 minutes 18 seconds, about 39 MB/s. rclone did it in under two minutes, about the speed the AWS CLI uploaded at. On a first read, CloudMounter gets you about 80% of the connection.

The second read is where File Provider pays off.

Big-file read times, first and second read

The first read runs close to line speed for both tools. The second read is the whole story: 3.1 seconds from CloudMounter's local copy.

CloudMounter read the same 5 GB again in 3.1 seconds. That is the SSD, not the cloud. rclone, going through the NFS layer, still needed 86 seconds with a full cache. Its warm reads topped out around 62 MB/s, barely above its first read.

If you load the same weights into a notebook ten times a day, that is the difference between seconds and roughly fifteen minutes.

Big Folders: The Flag That Changed My Conclusion

Next, a folder with 10,000 files. CloudMounter listed it in 141 seconds, with its encryption switched on. Its team tells me listing gets faster with encryption turned off in the connection settings. rclone on defaults took 469 seconds, and a few minutes later it took 426 seconds again.

I nearly wrote that down as a clean CloudMounter win. Then I read the rclone S3 docs. By default rclone stores its own modification time as object metadata, and reading it "takes an additional HEAD request" per file. On top of that, the directory cache expires after 5 minutes.

One flag removes the per-file request:

--use-server-modtime # use the S3 upload time, skip one HEAD per object

Listing a 10,000-file folder, rclone default vs tuned

Same folder, same bucket. One rclone flag takes the cold listing from almost eight minutes to three seconds.

With it, the same cold listing took 3.3 seconds. So the fair version is this: with zero tuning, CloudMounter browses big folders far faster than rclone. Against a tuned rclone, its first listing is over forty times slower.

Once a folder is listed, CloudMounter shows it again in 0.02 seconds. Tuned rclone took 2.5.

Small Files: Where Every Mount Struggles

This is the test that matters most if you train models: reading thousands of small files one by one, the way a data loader walks an image folder.

Small-file read rates, cold and cached

Cold reads crawl for every mount because each file is its own round trip. Once cached, CloudMounter serves the same files at over 5,000 per second.

CloudMounter managed 1.2 files per second. I stopped it after almost fifty minutes and 3,515 files. All 10,000 would have taken over two hours. rclone did 6.2 per second on defaults and 9.7 with the flag.

Each file is its own round trip to S3, and a mount reads them one after another. The AWS CLI reached 95 files per second on the same files because it runs ten requests at once.

Once cached, CloudMounter served the same files at 5,240 per second. The cost is entirely in the first read.

Reproduce It on Your Own Bucket

Mount benchmarks are easy to get wrong, so here is the part that keeps them honest. Every read goes through a checksum, and the cold and warm passes are recorded separately:

def sha256_file(p, bufsize=8 << 20): h = hashlib.sha256() with open(p, "rb") as f: while chunk := f.read(bufsize): h.update(chunk) return h.hexdigest() secs, digest = timed(lambda: sha256_file(mount / "seed/large/checkpoint_5g.bin")) assert digest == manifest["large/checkpoint_5g.bin"]

The small-file test mirrors a data loader: list the folder, then open and hash each file in order. No tool returned a single mismatched byte across any run.

Three traps I hit along the way. First, a stopwatch on mount is meaningless with File Provider: after unmounting, the folder still lists from cache, so the next "mount" looks instant. Second, when you check that a write landed, count objects with length(Contents), because the AWS CLI's KeyCount stops being useful once a prefix passes 1,000 keys and paginates. Third, run each tool alone on the network. Two mounts downloading at once will both look slow.

Write down the rclone flags you used. The same tool is 140 times faster or slower depending on one of them.

What to Watch For

Disk is not free. The site talks about optimizing local storage, and that holds until you open things: after my reads, 6.2 GB sat on my drive. rclone with full caching kept 6.7 GB, so this is how caching works, not a CloudMounter flaw. Unpin folders you are done with.

Unmount does not make the folder disappear. After unmounting, the folder still listed every cached file.

There is no Azure Blob Storage connection. rclone and Mountain Duck both offer Azure, so if your data lives there, CloudMounter is out.

If you script your mounts, CloudMounter speaks AppleScript:

osascript -e 'tell application "CloudMounter" to mount (first connection whose name is "Bench")'

Final Thoughts

Scorecard of every read test

Every read test in one table. CloudMounter wins every second read, a tuned rclone wins every first read.

For a training job, do not point a data loader at any mounted bucket and hope. Sync the data set down once, or pin the folder in CloudMounter well before the job starts, so the slow first read happens while you sleep.

For everything else, the choice is about who does the tuning. If you want S3, Google Drive and an SFTP server in Finder with no config files, CloudMounter is the easiest thing I tested, and its cache makes everything after the first open feel local. If you script everything and stream big data sets, a tuned rclone or a sync step still wins.

Either way, measure the first read and the second read separately. Most mount benchmarks only report one of them.

Resources & References

Stay in Touch

Short takes and discussions on X → https://x.com/sebuzdugan

Practical AI / ML videos on YouTube → https://www.youtube.com/@sebuzdugan/

Partnerships & collabs → sebuzdugan@gmail.com

Originally published on Medium.