I have the M1 mac mini with a 256GB ssd. It is not a fresh disk---I now have only about 30GB remaining.

I am not interested in synthetic raw disk performance, but in performance on the APFS file system. so I tried writing bytes to a 4.8G file. (commas added by me):

% time dd if=/dev/zero of=1 count=10000000  
10000000+0 records in
10000000+0 records out
5120000000 bytes transferred in 20.313020 secs (252,055,086 bytes/sec)

At 252MB/s, this is not exactly endearing. Is this the number I should be expecting? (I know that there is overhead; I believe on an SSD, file fragmentation is no longer the issue it once used to be, however.)

read speed seems reasonable at 770 MB/sec:

% time dd if=1 > /dev/null    
10000000+0 records in
10000000+0 records out
5120000000 bytes transferred in 6.669058 secs (767,724,617 bytes/sec)
dd if=1 > /dev/null  2.03s user 4.40s system 96% cpu 6.677 total

PS: I compared this to performance on an external USB3 sandisk SSD 2TB, where I get about twice the write performance and about half the read performance. I also checked whether /dev/zero has special tricks (through comparison with /dev/random), but the modest deterioration on all drives suggests that my dd really does write zeros to ssd.

per darkdust's answer below, here are versions with 4096 block size:

  • mac mini 256gb internal relatively full: write 1.5GB/s, read 0.75GB/s.
  • external usb3 sandisk 2tb relatively empty: 0.4GB/s, read 0.4GB/s.
  • And, for kicks, a Samsung Extreme Thunderbolt: 0.5GB/s write, 0.4GB/s read.
  • 2
    This article is about SSD performance on M1 Macs and I found it enlightening how difficult it is to accurately measure SSD performance accurately. Hopefully you will find something in it to put your measurements into perspective eclecticlight.co/2022/04/22/… May 19 at 12:21
  • Use an app like BlackMagic Disk Speed Test for standardized results. Also, it's likely that the lack of free space may be a factor.
    – benwiggy
    May 19 at 12:32
  • I think BM Disk Speed Test measures raw disk throughput, not file-system intermediated throughput.
    – ivo Welch
    May 19 at 18:31

2 Answers 2


dd is a very bad tool to measure disk performance. It's using a block size of 512 bytes by default, which on an SSD is far from optimal.

On the shell, you can determine your SSD's block size via diskutil info /, e.g.:

$ diskutil info / | grep Block
   Device Block Size:         4096 Bytes
   Allocation Block Size:     4096 Bytes

So let's compare the default 512 byte blocks vs. 4096 blocks (mind the count to get the same number of bytes):

$ dd if=/dev/zero of=test count=800000
800000+0 records in
800000+0 records out
409600000 bytes transferred in 2.173086 secs (188,487,708 bytes/sec)

$ dd if=/dev/zero of=test count=100000 bs=4096
100000+0 records in
100000+0 records out
409600000 bytes transferred in 0.323270 secs (1,267,052,309 bytes/sec)

That's quite the difference! How about reading and writing in one go?

$ dd if=/dev/zero of=test count=1 bs=409600000
1+0 records in
1+0 records out
409600000 bytes transferred in 0.118812 secs (3,447,463,219 bytes/sec)

Even better!

Conclusion: do not use dd to measure disk performance.

  • interesting. I would have thought dd would buffer through the underlying OS layer to the right block size, but obviously my assumption was wrong. To the extent that normal read/writes are buffered, the block-size appropriate dd is more representative. will add second measures to my original post above to point out the difference, too.
    – ivo Welch
    May 19 at 18:15

Your write test was done at 252MB/s, not KB/s. Still, this is extremely low for an M1 SSD. (As well as the read speeds).

To speed up writes to an SSD, one must regularly send TRIM commands to the SSD, which informs the disk about which blocks are no longer being used. On macOS, there is no manual trigger, however rebooting will work (or at least it did so back when verbose booting was an option).

Still, I wouldn't expect that much performance degradation (unless Apple was using even worse SSDs than previously thought). The issue is most likely that you are copying 512 bytes at a time from /dev/null, then writing that single 512 byte block to the disk. Try using the bs= argument with dd, somewhere around 32M or 64M should deliver appropriate results on an SSD.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .