TerraMaster Forum

F4-425 Pro / TOS 7: SMB Write Performance — Finder vs. cp vs. ditto

Hello everyone,

I'd like to share the results of my SMB performance tests on a TerraMaster F4-425 Pro running TOS 7.

I noticed a significant difference in large-file write speeds depending on whether I use macOS Finder, cp, or ditto. I'm interested in finding out whether other TerraMaster users have experienced similar behavior.

1. Hardware and Network Setup

NAS
- Model: TerraMaster F4-425 Pro
- OS: TOS 7
- RAM: 32 GB
- SATA RAID 1: 2 × Samsung 870 EVO 2 TB (system and data)
- NVMe RAID 5: 3 × Samsung 970 EVO Plus 500 GB
- Storage stack: Linux mdraid → LVM → Btrfs

Mac
- Mac mini M4, 16 GB unified memory
- macOS Sequoia
- ACASIS NT0201 Thunderbolt-to-10GbE adapter (Aquantia AQC113)

Network
- Direct Ethernet connection between Mac and NAS
- Negotiated speed: 5 Gbps
- MTU: 8192 on both devices
- SMB version: 3.1.1
- SMB Multichannel: Disabled
- SMB encryption: Disabled

2. Network Performance (iperf3)

I ran iperf3 in a Docker container using host networking on the NAS.

Results:
- Mac → NAS (4 TCP streams): ~4.95 Gbps
- NAS → Mac (4 TCP streams): ~4.95 Gbps
- Mac → NAS (1 TCP stream): ~4.95 Gbps

The network connection performs close to its 5GbE limit in both directions.

3. Local NVMe RAID 5 Write Performance (fio)

I tested sequential writes directly on /Volume2, bypassing SMB.
All tests used a 16 GiB file, direct I/O (direct=1), and a final fsync.

Results:
- 1 MiB blocks, QD16: 1,545 MB/s
- 1 MiB blocks, QD1: 728 MB/s
- 256 KiB blocks, QD1: 565 MB/s
- 64 KiB blocks, QD1: 185 MB/s
- 64 KiB blocks, QD16: 1,137 MB/s

The RAID 5 array is healthy ([3/3] [UUU]), with no background synchronization.
These results show that the array is capable of high sequential write throughput, although performance depends heavily on block size and queue depth.

4. SMB Write Performance: Finder vs. Terminal

This is the most interesting part.

I copied the same 17,806,604,888-byte (17.81 GB) file from the Mac's internal SSD to the NVMe RAID 5 SMB share (Storage_2).

Results:
- Finder (original file): 53 seconds — 336 MB/s
- Finder (copy without quarantine attribute): 50 seconds — 356 MB/s
- Terminal (cp): 33.07 seconds — 538 MB/s
- Terminal (ditto): 28.94 seconds — 615 MB/s

Commands used:

cp: ditto: The difference is substantial.
In these tests, Finder achieved approximately 335–355 MB/s, while ditto reached approximately 615 MB/s.

I also created a separate copy of the file without the com.apple.quarantine extended attribute. This did not significantly improve Finder performance.

For comparison, cp achieved approximately 439 MB/s when writing the same file to the SATA RAID 1 share (Storage_1).

Important note: The SMB speeds above were calculated by dividing the file size by the total copy completion time. They do not independently verify that all data had been physically flushed from the NAS RAM to the SSDs.

5. Relevant Samba Settings

The following values were reported by testparm:
The aio write size = 4096 setting applies to the shared folders.

RAID 5 and Btrfs settings:
- RAID chunk size: 64 KiB
- Stripe cache size: 4096
- Btrfs mount options: rw,noatime,ssd,tmacl,space_cache=v2

CPU utilization remained relatively low during SMB transfers. The smbd process did not appear to saturate a CPU core.

6. Observations

Based on these tests:
- The physical 5GbE network connection does not appear to be the bottleneck.
- The NVMe RAID 5 array is capable of significantly higher write throughput than the speeds observed with Finder.
- SMB transfers using cp and especially ditto complete substantially faster than transfers using Finder.
- Removing the quarantine attribute did not eliminate the performance difference.
- No SMB encryption or background RAID synchronization was active during testing.

I have not yet determined exactly why Finder performs more slowly.
Possible factors include differences in SMB write patterns, metadata handling, caching, or macOS file-copy behavior.

7. Questions for the Community

- Has anyone experienced significantly slower SMB transfers using macOS Finder compared with cp or ditto on TOS 7?
- Could Finder's SMB write behavior, metadata handling, or caching explain this difference?
- Are there any recommended Samba settings specifically for improving large-file SMB writes from macOS?
- Have other F4-425 Pro owners achieved consistent 500–600 MB/s write speeds through Finder over a single 5GbE connection?

I'd prefer not to disable SMB security features or modify filesystem and RAID settings without identifying the actual cause.

Any feedback, comparable benchmarks, or insights from TerraMaster developers would be greatly appreciated.

Thanks!

Crashoveride wrote: ↑Yesterday, 16:33

First of all, thank you for sharing such a thoroughly documented, rigorous, and well-structured benchmark! Testing iperf3, raw fio array baselines across different block sizes and queue depths, and contrasting CLI vs. GUI copy operations provides fantastic insight into how macOS interacts with the TOS 7 storage stack.

Since ditto is hitting 615 MB/s (~4.92 Gbps), your 5GbE link, the NVMe RAID 5 array, and smbd itself are clearly maxing out the wire.

The drop-off you're seeing with Finder (~335–355 MB/s) compared to cp/ditto on the exact same mount comes down to how macOS handles GUI copies vs. raw CLI streams, combined with how Samba's "strict sync = Yes" reacts to it:

1. Queue depth drops
Your fio test shows the Btrfs RAID 5 array doing 1,137–1,545 MB/s at QD16, but dropping to 185–565 MB/s at QD1.
When you run ditto or cp, they just blast sequential writes and keep the SMB credit window full (high queue depth). Finder's copy engine is much more conservative—it pre-allocates space (F_PREALLOCATE), paces writes to update the UI progress bar, and does synchronous checks in between. That effectively drags the queue depth down toward QD1 territory.

2. Mid-transfer SMB FLUSH + "strict sync = Yes"
Unlike ditto (which writes straight through and flushes at EOF), Finder periodically sends SMB2 FLUSH requests while the copy is still running.
Because TOS 7 has "strict sync = Yes" enabled, every single flush from Finder forces smbd to call fsync() all the way down through LVM and Btrfs. Even on NVMe, constantly draining the write queue and committing Btrfs metadata transactions mid-flight causes micro-stalls, which usually caps Finder right around that 300–360 MB/s mark.

3. Finder metadata chatter
Even after stripping com.apple.quarantine, Finder still sets temporary FinderInfo flags while copying, checks ACLs/streams, and talks to Spotlight/mds. Each of those metadata calls is synchronous and briefly stalls the async write pipeline.

How to verify this without changing your security or filesystem settings:


Since you mentioned wanting to pinpoint the cause before changing any settings, the cleanest way to see this in action is to watch smbd directly on the NAS during a transfer.

1. Compare syscalls with strace (read-only)
Grab the smbd PID for your Mac session using "smbstatus -p", then run this while copying the 17.8 GB file via Finder, and again via ditto: You'll immediately see the difference in the number of fsync/fdatasync and xattr calls, as well as how pwrite64 calls are grouped.

2. Quick test with "strict sync = No"
If you just want to confirm whether the mid-transfer flushes are the main bottleneck, try temporarily setting: for that share and reloading smbd. That lets the Linux page cache absorb Finder's mid-copy flushes without stalling the Btrfs write pipeline. In most cases, Finder speeds jump right up next to cp. (You can switch it right back to Yes after testing).

3. Client-side macOS tuning
Without touching SMB signing or security settings, you can also test disabling client-side file ID lookups on your Mac by adding this to /etc/nsmb.conf (requires remounting the share): This cuts down some of the extra metadata lookups Finder makes over SMB and often helps smooth out GUI transfers on 5GbE/10GbE links.

Your benchmarks clearly demonstrate that the F4-425 Pro hardware and TOS 7 Samba stack have no trouble delivering full 5GbE wire speed.

Thanks again for this top-tier contribution to the community!

Crashoveride wrote: ↑Yesterday, 16:33

Bonjour. Bien que je dispose d'un réseau Ethernet local de 10 gbs, j'ai longtemps essayé d'optimiser mes transfert entre mes PC et un de mes NAS. Je n'ai malheureusement pas de MAC et ma machine NAS de test est un Qnap avec une carte PCIE/ethernet de 10gbs.

Il y a une valeur qui m'a étonné dans ce que tu indiques :

MTU: 8192 sur les deux appareils

Peut-être que sur un réseau sans switch (notamment des switchs non managés ou de type ouvert) un tel réglage peut être positif. Mais sur mon réseau 10g très diversifié, toutes mes tentatives de changer la MTU classique de 1500 ce sont traduites par une baisse des vitesses de transfert entre mon PC équipé d'un NVME et mon NAS qnaps avec NVME Samasung 990 Pro. Pour atteindre de vrais bon débits sans surprise, je suis très vite revenu à une MTU "Classique".

Ceci dit, je ne suis pas informaticien et mes transferts ont été effectués depuis une machine windows et le NAS, avec une moyenne assez stable de 900 Mo/s. Lorsque "je jouais" avec la MTU sur tous les points configurables, y compris la carte réseau coté PC et coté NAS, ces transferts sont devenus assez irréguliers avec mon gros fichier de test (près de 40go...). Windows utilise bien sur du smb et je n'ai rien changé aux sécurités.

Je pense que ma réaction ne t'apportera pas grand chose, mais je tenais à te faire part de "mes essais" réels. Pourtant, c'est un conseil récurent sur le net : "Augmentez votre MTU". Je pense que ce n'est valable que dans des situations bien particulières et quand toute la chaine et tous les appareils sont "managés"... J'avoue, un de mes switchs 10 gbs n'a aucune interface de gestion. C'est peut-être lui qui galérait un peu avec des MTU proches de 9000... Sur le papier, pourtant, avoir moins de "découpe" semble un vrai gain.

Cordialement...

EriChan wrote: ↑Yesterday, 20:20

Thank you for your suggestions!

I've performed additional diagnostics using strace on the TerraMaster F4-425 Pro running TOS 7.

I monitored the Samba process (smbd, PID 6469) while copying the same 17.81 GB file from my Mac mini M4 to the NVMe RAID 5 SMB share.

Results

macOS Finder
- 29 fsync system calls recorded
- Total time spent in fsync: 8.22 seconds
- Average duration per call: approximately 283 ms
- Previous copy times: 50–53 seconds

macOS ditto
- Copy completed in 30.99 seconds (~575 MB/s)
- No fsync calls appeared in the captured output, although strace did not produce a summary table, so this result is not conclusive

These findings seem to support your hypothesis that Finder generates additional synchronization operations, potentially contributing to its slower SMB write performance.

My questions

- Can TerraMaster confirm whether these fsync calls are triggered by SMB FLUSH requests from macOS Finder?
- Is there a recommended way to reduce their performance impact without disabling strict sync or compromising data integrity?
- Could this behavior be improved through Samba configuration or a future TOS 7 update?

I would prefer to keep strict sync = yes to preserve reliable write semantics.

Thank you for your assistance!

Alak wrote: ↑Yesterday, 21:52

Thank you for sharing your experience!

Interestingly, I actually encountered similar issues with Jumbo Frames.

When I initially configured MTU 9000 on both my Mac mini M4 and TerraMaster NAS, data transfers failed completely. Switching to MTU 8192 resolved the problem, and file transfers became stable.

Although I later managed to get MTU 9000 working after additional adjustments, I ultimately decided to stick with MTU 8192.

With this configuration, `iperf3` consistently delivers approximately 4.95 Gbps in both directions over my direct 5GbE connection.

I haven't performed a controlled performance comparison against MTU 1500 yet, so I can't claim that Jumbo Frames provide a measurable speed advantage in my setup.

I've also ordered a 10GbE switch and plan to repeat the tests once it arrives.

Your experience reinforces an important point: higher MTU values don't necessarily guarantee better performance or stability. Compatibility across the entire network path matters much more.

Thanks again for sharing your findings!

Vos mises à jour sont devenues nombreuses et quotidiennes.
A propos de ceux qui souhaiteraient automatiser les certificats tel que : Let's Encrypt rattachés à des domaines privés : Nous avons rédigé un script qui perdure inutilisable ou risque d'être corrompu par une mise à jour …?
TOS 7 ne comporte une énorme lacune : Aucun raccordement à nginx.conf, pas de lien symbolique, aucune copie sur le disque système. Je ne trouve aucun script communautaire, aucune fonction officielle de la part de TerraMaster ? Tout cela est annoncé comme étant programmé, mais rien n'est traité ??? Les mois s'écoulent et tous ceux qui utilisent principalement le httpS sont ignorés ! Cordialement.

Three out of four devices updated to 1536. F4-425 Plus staying at 1422 for now.
OpenClaw is working fine on F4-424 Pro while the other three devices are remote clients.

Asdrubal wrote: ↑Yesterday, 23:55

Merci pour votre retour. Nous comprenons parfaitement votre besoin concernant l'automatisation des certificats SSL (tels que Let's Encrypt) pour les domaines privés.

Cette fonctionnalité est déjà enregistrée dans notre feuille de route (backlog) et fait l'objet d'une planification par notre équipe produit. Nous avons de nouveau transmis votre demande à l'équipe R&D afin d'appuyer sa priorité, et nous vous tiendrons informé dès qu'une mise à jour sera confirmée.

Merci encore pour votre patience et votre compréhension !

---

Thank you for your feedback. We completely understand your need for automated SSL certificate management (such as Let's Encrypt) for private domains.

This feature is already logged in our product backlog and is currently being scheduled by our product team. We have forwarded your follow-up to the R&D team to help prioritize it, and we will keep you updated as soon as it is confirmed for an upcoming release.

Thank you again for your patience and understanding!

No junk, and the web interface loaded on its own! I have nothing left to dream about!
Thx!

Crashoveride wrote: ↑Yesterday, 22:14

Great catch with strace—29 fsync calls across a 17.81 GB file shows Finder is forcing a flush checkpoint roughly every ~600 MB (~512 MiB chunks).

To answer your questions directly:

1. Are these fsync calls triggered by SMB FLUSH from Finder?

• Yes. With "strict sync = Yes" and "sync always = No", smbd never calls fsync() on normal writes—it only calls fsync() when the client explicitly sends an SMB2 FLUSH request.

• Those 29 flushes explain the entire ~20s slowdown: ~8.2s is spent directly inside fsync(), and the remaining ~12s is lost because each flush drains Finder's in-flight write queue and forces it to ramp queue depth back up from QD1 29 times.

2. Can the impact be reduced while keeping "strict sync = Yes"?

Because the ~512 MiB flush interval is hardcoded in macOS Finder, and "strict sync = Yes" requires Samba to honor every flush by committing Btrfs transactions and flushing hardware caches across the 3 NVMe drives in RAID 5 (~283 ms per flush), you can't bypass those 29 fsyncs via Samba config without breaking strict sync semantics.

If you want to keep "strict sync = Yes" untouched:

• Use ditto / cp (or a streaming third-party file manager) for huge single files—flushing once at EOF provides the same final data integrity without stalling 29 times mid-transfer.

• You can still add "file_ids_off=yes" in /etc/nsmb.conf on the Mac to trim extra metadata round-trips without affecting write safety.

3. Can this be improved in future TOS 7 updates?

We will forward your strace data to our R&D team to evaluate whether there are optimization paths for this in future TOS 7 releases.

Thanks again for sharing such solid diagnostic data!