Thank you for your previous explanation and for forwarding my findings to the R&D team.
I've now performed additional network-level diagnostics using tcpdump and Wireshark's tshark to investigate the SMB FLUSH behavior.
I captured SMB traffic between my Mac mini M4 and TerraMaster F4-425 Pro while copying the same 17.81 GB file to the NVMe RAID 5 volume.
Results
macOS Finder
- 27 SMB FLUSH requests detected
- Previous copy times: approximately 50–53 seconds
- Network capture: 421,230 packets, with zero kernel drops
macOS ditto
- 0 SMB FLUSH requests detected
- Previous copy time: approximately 31 seconds
- Network capture: 400,413 packets, with zero kernel drops
Both captures used the same filter (tcp port 445 and less 512) and were analyzed using the same Wireshark display filter (smb2.cmd == 7).
Since the capture filter excluded packets of 512 bytes or larger, these counts may not represent every SMB FLUSH request.
These findings are consistent with my earlier strace results, which showed 29 fsync calls taking a total of 8.22 seconds during Finder copying.
I also tested your suggested macOS setting, file_ids_off=yes. Unfortunately, it made no measurable difference: Finder still required approximately 53 seconds to copy the file.
The additional network evidence strongly supports your explanation that Finder's SMB FLUSH behavior contributes to the performance difference compared with ditto.
I hope these results will be useful to your R&D team when investigating possible SMB performance improvements in future TOS 7 releases.
Thank you again for your assistance!
