In what is becoming a kind of hobby for me, I've just finished testing another tiny NAS—more on that tomorrow.

But as I was testing, I started getting frustrated with the fact I've never been able to get a Raspberry Pi—regardless of internal storage speeds, even with 800+ MB/sec PCIe-based storage—to consistently write more than around 100 MB/sec write speeds over the network, with either Samba or NFS.

NFS would be more consistent... but it ran around 82 MB/sec:

Samba would peak around 115 MB/sec, but it was wildly inconsistent, averaging around 70 MB/sec:

I have a problem: I use macOS1.

This blog post isn't about whether macOS is good or bad, but it is about network shares on macOS. And quantitatively, through the years, network shares on Mac OS, Mac OS X, and macOS have always been bad.

No matter what incantations I tried, with NFS, Samba, client, or server—and yes, I've even spoken to one of the Samba devs about it—there was no way to get beyond 100 MB/sec write speeds on the Pi from my Mac2.

Read speeds were always fine, when copying from the Pi to my Mac. I could peg it at 122 MB/sec over the Pi's 1 Gbps connection, and 230 MB/sec over a 2.5 Gbps connection (courtesy of the Pineberry Pi HatNET! 2.5G).

I started wondering if the problem was truly on the Raspberry Pi after tkaiser recommended monitoring more deeply with atop. I didn't see anything amiss, and the Pi had a ton of headroom (CPU, network, interrupts, and disk IO were all well in hand).

So that led me down a rabbit hole of testing:

• I verified using iperf3 that my network connections were at line speed. iperf3 showed 940 Mbps to and from on the 1 Gbps LAN, and about 2 Gbps on the 2.5 Gbps connection—lower than the normal 2.35 Gbps because it's through a PCIe Gen 2 packet switch.
• I verified using iozone that my storage was writing through at over 800 MB/sec to a 4-drive RAIDZ1 array of SATA SSDs (tested with a 50 GB test file in 1M chunks).
• macOS Sonoma doesn't seem to have an /etc/nsmb.conf file by default, but according to many, in past macOS releases adding signing_required=no in this file would speed things up by disabling Samba packet signing (a security feature not really required on LANs).
• It didn't seem like signing was active on this connection, from all my research, but I did spend an hour or so force-disabling it everywhere... which made no difference.
• I tried a bunch of other server-side tweaks, none of them seemed to make any difference.
• I tried using cp and rsync to see if it was just the Finder where this issue cropped up—both were more consistent in their write speed to the share, but slower overall.
• I fired up Transmit, my SFTP client, and copied the same directory over using SSH / scp, and it copied at 112 MB/sec, very consistently. Yay for SSH file copies being faster than Samba, I guess!

I'll spare you many hours of debugging—I eventually booted up my Windows 11 PC and ran all the same tests, with the same 50 GB video project folder3.

On there?

Consistent 108 MB/sec write speeds for the entire copy over the 1 Gbps connection.

And then it ran at 150 MB/sec over the 2.5 Gbps connection. (The bottleneck, in this case, is the PCIe Gen 2 switch, used to install a 2.5G PCIe NIC in addition to four SATA SSDs on the Pi 5's single PCIe lane. More on that tomorrow!)

Read speeds are the same from macOS to Windows, though. Since ZFS doesn't need to do the parity calculation and writes, it can read out from the four drive array a bit faster.

What I still don't understand is where the bottleneck lies on macOS's side. I don't see anything that screams bottleneck when monitoring with Activity Monitor or htop on my Mac. And I don't know of any equivalent to atop that will let me monitor interrupts and other resources like I can on Linux.

Any other ideas why macOS is so bad at writes to network shares?

I guess I should be happy network shares work at all though... in the past I would fight against macOS's built-in NFS support to even get them mounted!