The macOS Storage Speed Myth, Part 1: Decoding SSD Benchmarks and Real-World File Operations

Preface

Apple’s pricey storage upgrades push many Mac users to explore cost-effective alternatives. In this series, we dive into external Thunderbolt/USB4 NVMe enclosures and SSDs—a high-performance, budget-friendly way to expand your Mac’s storage. This first installment lays the groundwork, explaining why the blazing-fast speeds advertised for Mac storage and external SSDs often don’t match real-world performance. By understanding how macOS handles file operations, you’ll be better equipped to choose the right external drive in our upcoming tests.

The Problem

Why Your Mac’s Blazing Fast Storage Speeds Don’t Matter for File Copying

Reviewers love to tout the “blazing fast” internal storage of newer Macs, boasting numbers like 6300 MB/s read and 5200 MB/s write from tools like Blackmagic Disk Speed Test. My 4-year-old M1 Max Mac Studio (512GB SSD, ~70% full) reports 5085 MB/s read and 4400 MB/s write.

But these numbers rarely reflect real-world tasks like file copying, app launching, or even video editing. Here’s why those headline speeds are misleading and what to focus on when choosing an external SSD.

The Benchmark Myth: What Those Numbers Really Mean

When you see speeds like 6300 MB/s, it’s tempting to think you’ll copy a 6.3 GB file in one second. In reality, copying a large video or a folder of photos feels much slower. Benchmarks like Blackmagic push SSDs to their limits with idealized conditions—large, sequential data transfers and high queue depths (multiple simultaneous data requests). But everyday tasks like file copying involve smaller, less predictable data transfers that can’t fully utilize the SSD’s raw power.

Benchmarks like Blackmagic Disk Speed Test are designed to measure the raw performance of your Mac’s storage hardware, typically an NVMe SSD in modern Macs like the M1 Max Mac Studio. These tests issue large, sequential read and write operations with high queue depths (multiple simultaneous I/O requests) to stress the storage controller and measure its peak throughput. For example, Blackmagic uses large block sizes (e.g., 1MB) and high queue depths (e.g., 8 or 32) to saturate the NVMe SSD’s capabilities.

In contrast, real-world file copying in macOS—whether you’re dragging files in Finder or using the cp command—doesn’t come close to these conditions. File copying is a complex process involving user-space applications, system calls, the file system, and the storage stack, all of which introduce overhead that limits performance far below the benchmarked maximum.

How macOS Copies Files: A Peek Under the Hood

To understand why file copying doesn’t hit those blazing benchmark speeds, let’s break down what happens when you copy a file on macOS.

Step 1: User-Space Initiation

When you drag a file in Finder or run cp source.txt dest.txt in Terminal, a user-space application kicks off the process. In Finder, this is handled by the NSFileManager API, which calls methods like copyItemAtPath:toPath:error:. In the command line, tools like cp or rsync directly invoke system calls. These applications don’t directly access the SSD; they rely on macOS’s kernel and file system to do the heavy lifting.

Finder, for example, prioritizes user experience—think progress bars and smooth system responsiveness—over raw I/O performance. It typically processes file copies in a single-threaded or lightly parallelized manner, reading and writing data in chunks (called buffers) that are much smaller than the massive block sizes used in benchmarks.

Step 2: System Calls and Data Transfer

At the core of file copying are a handful of Unix system calls, inherited from macOS’s BSD roots:

• Opening Files: The open(2) system call opens the source file for reading (O\_RDONLY) and the destination file for writing (O\_WRONLY | O\_CREAT | O\_TRUNC).
• Reading and Writing: The read(2) call fetches a chunk of data (typically 64 KB to 1 MB) from the source file into a memory buffer, and write(2) writes that chunk to the destination. This process repeats until the entire file is copied.
• Metadata Handling: Calls like fstat(2), fchmod(2), and fsetxattr(2) copy metadata (permissions, timestamps, Finder tags, etc.) to the destination file.

Here’s a simplified version of what cp might do:

int src_fd = open("source.txt", O_RDONLY);
int dst_fd = open("dest.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
char buffer[131072]; // 128 KB buffer
ssize_t bytes_read;
while ((bytes_read = read(src_fd, buffer, sizeof(buffer))) > 0) {
    write(dst_fd, buffer, bytes_read);
}
close(src_fd);
close(dst_fd);

This sequential read-write loop is efficient but doesn’t exploit the full parallelism of modern NVMe SSDs, which can handle dozens of simultaneous I/O requests (high queue depth).

Step 3: The Role of APFS

macOS’s default file system, APFS (Apple File System), plays a significant role in file copying. APFS is optimized for SSDs and includes features that can make copying faster—or slower—depending on the scenario.

One standout feature is copy-on-write (CoW) cloning. If you copy a file within the same APFS volume (e.g., from one folder to another on your Mac’s internal SSD), macOS may use the clonefile(2) system call. This creates a clone of the file—a metadata operation that references the same data blocks on disk without duplicating them. Cloning is nearly instantaneous and uses almost no additional disk space until the source or destination file is modified. For example, copying a 10 GB video file within the same volume might take milliseconds because no actual data is copied.

However, cloning only works within the same APFS volume. Copying across volumes (e.g., to an external USB drive or a network share) or to a different file system (e.g., FAT32 or exFAT) requires a full data copy, which is much slower.

Step 4: Storage and I/O Bottlenecks

Even with a blazing-fast NVMe SSD, file copying is limited by several factors:

• Queue Depth: Benchmarks like Blackmagic use high queue depths (e.g., 8–32 simultaneous I/O requests) to maximize throughput. In contrast, Finder and cp typically issue 1–4 I/O requests at a time, resulting in low-to-moderate queue depth. This means your SSD is rarely saturated during a file copy.
• Payload Size: Benchmarks use 1MB blocks, while macOS file copies sometimes use smaller buffers (512KB). Smaller buffers mean more frequent I/O operations, increasing overhead.
• Caching: macOS’s unified buffer cache stores data in RAM before writing to disk, which can delay writes and add overhead. While caching improves performance for small files, it doesn’t help large sequential transfers match benchmark speeds.
• Metadata Overhead: Copying small files or directories is particularly slow because each file requires metadata operations (e.g., creating directory entries, setting permissions), which involve multiple small I/O requests.

For example, copying a 10 GB video file might achieve ~2000 MB/s on an M1 Max Mac Studio, far below the 4400 MB/s read speed reported by Blackmagic. Copying thousands of small files (e.g., a photo library) is even slower, as metadata operations dominate.

Putting it to the Test: Real-World Evidence

I tested my M1 Max Mac Studio (512GB SSD, ~70% full) running macOS Sequoia 15.5 to compare synthetic benchmarks with real-world tasks, using a 19.85GB LLM model file.

1. The Baseline: High-Speed Synthetic Benchmarks

As mentioned, Blackmagic Disk Speed Test is often quoted for raw speeds. My internal SSD achieves:

• Read: 5085 MB/s
• Write: 4400 MB/s

To further illustrate these ideal conditions, I used AmorphousDiskMark, a popular macOS benchmark tool that allows for specific control over test parameters. When configured to simulate large, sequential transfers at high queue depths (like QD64), the results are similarly impressive.:

This baseline confirms the raw, theoretical throughput of the internal SSD under optimal, synthetic conditions.

By utilizing a powerful Mac default app called Instruments, we can record the I/O requests and analyze them in a user-friendly way. Here’s what happened during the Black Magic Disk Speed Test.

Observation: Highly sustained write operations. Writes occur every 20-30 microseconds with 1MB blocks. Multiple 1MB Data Write calls queued and started within the same 1-2 microseconds range, suggesting high queue depth.

Now we have the baseline established, we can move on to some real life tests. I will be using an LLM model file that’s about 19.85GB in size.

2. File Copy Operations

2-1. Finder Copy - Internal SSD, One Folder to Another

I copied the LLM file from one folder to another within the Apple internal SSD. As expected, the operation was instantaneous, suggesting the data file itself hasn’t actually been moved, only the metadata was rewritten.

2-2. cp Copy - Internal SSD, One Folder to Another

Using time and Instruments, I copied the LLM file with cp. It took 10.328 seconds (~1.98 GB/s).

Observation: cp uses 1MB blocks with moderate concurrency (low queue depth), way less than benchmark speeds.

2-3. Finder Copy - External SSD to Internal SSD

I am using my Samsung 980 Pro 2TB PCIe 4.0 SSD installed in previously reviewed Lekuo NVMe USB4 enclosure. Here’s the condition of the disk, for which has certainly seen some action.

I copied the same LLM model from the external Samsung drive to the internal Apple SSD, as well as recorded the I/O operations with Instrument, and here’s the results.

Observation: Similar to Blackmagic Disk Speed Test and cp copy, macOS Finder uses 1MB block to transfer the files. What’s distinctly different is that Finder only issues one write command at a time, often waiting between 150-400 microseconds between each call, which is indicative of a typical QD1 operation. Total operation took about the same time as the cp command, which is about 1.98GB/s per second of transfer speed. Considering this is coming from an heavily-used external drive to the internal drive, the result is good enough.

2-4. Finder Copy - Internal SSD to External SSD

Copying from the internal SSD to the external SSD took ~6 seconds (~3.3 GB/s).

Observation: Smaller 512KB blocks but faster transfer, likely due to the Samsung 980 Pro’s superior IOPS and better controller.

2-5. cp Copy - External SSD, One Folder to Another

Copying within the external SSD took ~8 seconds (~2.48 GB/s).

Observation: Similar 512KB blocks but faster than internal SSD, highlighting the Samsung SSD’s high IOPS.

Conclusion

No file copy matched Blackmagic’s speeds. Here’s a summary:

3. Launching Applications

App launches involve many small, random I/O operations (4KB–64KB), relying on an SSD’s random 4K IOPS (input/output operations per second) rather than sequential speed.

3-1. Internal SSD, Final Cut Pro and Xcode

Now, let's look at how the drive performs under conditions more representative of typical macOS user scenarios. For this, we'll examine the filesystem I/O characteristics when opening two applications that I found are the slowest to launch: Final Cut Pro and Xcode.

First, let’s take a look at launching Final Cut Pro. Instrument reported that during the 20 seconds or so start-up process, FCP has read about 728MB of data, while written less than 10MB. Let’s take a look at what’s happening inside.

As we can see, the log file is absolutely littered by small file I/O operations that come nowhere close to the 512KB payload size when doing file copy in Finder, let alone the 1MB block size used by Blackmagic Disk Speed Test.

Then, let’s take a look at timeline scrubbing. This operation is considered by many people that it will absolutely stress out the SSD thus you will need to buy the best and fastest SSD to edit videos.

So I created a new project, imported a dozen or so 4K videos shot from my iPhone 15 Pro, dropped them into the timeline, and fanatically scrubbed the timeline for about 10 seconds. Here’s the result.

At the beginning, the videos are read from the external SSD with up to 512KB block size.

When scrubbing timeline, the data access pattern is mostly randomized 512KB QD1, evidenced by the many more than 1ms latency, or seek time.

Xcode is up next. I have a small iOS project at hand so the process will include loading the iOS project files from the Xcode start-up menu. It took about 13 seconds for Xcode to start up and drop me at the project root. During the start-up process, Xcode read about 207MB from the SSD, while writing less than 7MB.

Observation: No matter where you look, the result is consistent with our thesis. Launching applications do not involve consistently large block size I/O, thus the SSD will not get near the max speed advertised by SSD manufacturers and reviewers. These small 4KB–64KB I/O operations, typical of app launches, rely on the SSD’s random IOPS performance (often less than 20,000 read and less than 50,000 for write IOPS for modern NVMe SSDs) rather than sequential throughput. This explains why even a ‘slower’ SSD can feel just as snappy for launching apps.

Take Aways

Our tests reveal why benchmark speeds don’t tell the whole story for macOS storage performance:

• Benchmarks Overpromise: Blackmagic’s 5085 MB/s read and 4400 MB/s write reflect idealized conditions (large 1MB–5MB blocks, high queue depths). Real-world file copying uses smaller 512KB–1MB blocks and low queue depths (1–4), hitting 1980–3300 MB/s—fast, but not benchmark-fast.
• APFS Cloning Saves Time: Copying within the same APFS volume is instant due to copy-on-write cloning, but this doesn’t apply to external drives or non-APFS systems, where full data transfers slow things down.
• External SSDs Can Outshine: The Samsung 980 Pro in a USB4 enclosure hit 3300 MB/s in some tests, surpassing the internal SSD thanks to its Elpsis controller and high IOPS. Modern external SSDs are powerful for tasks like video editing.
• App Launches Need IOPS: Launching apps like Final Cut Pro or Xcode involves small 4KB–64KB random I/O, relying on an SSD’s IOPS and low latency, not sequential speed. A “slower” SSD can still feel responsive here.
• Choose SSDs Wisely: For external SSDs, prioritize random 4K IOPS and low latency for tasks like app launches or media editing. Don’t be swayed by peak sequential speeds alone.

In Part 2, we’ll test Thunderbolt/USB4 NVMe enclosures and SSDs to find the best options for your Mac, focusing on real-world performance for your workflow, not just benchmark numbers. Stay tuned!