Hi. Here also still the same. Eg. deleting a folder containing many files is an overnight operation from a Mac client on a TrueNAS server. We're doing film post-production. We have accepted that TrueNAS doesn't play well with folders containing many files (image sequences) and Mac clients and settled with using direct attached NVME drives for that and only using the servers for single video files and archiving. This seems not even a TrueNAS problem but a general issue with open source Samba.
What did definitely help a bit is to disable the Apple Extensions.
View attachment 74478
We tried SMB multichannel and that might have improved the situation a bit but not substantially.
Linux clients don't show any of those problems.
iSCSI shares on TrueNAS obviosuly don't show those problems but then there's not shared access. We tested TigerStore, which lets you share iSCSI volumes among clients. This does work well and fast also with image sequences and Mac clients but is a rather complicated setup so we didn't go for it yet.
Seems to be an unsolved problem for now and if you need to work with accessing directories containing many files from Mac clients over SMB on TrueNAS (or any open source server) this will simply not be a viable thing.
Yeah, it really is a shame. I did originally search for discussions about samba, but there seemed to be the most activity on these TrueNAS forums. After looking into it more, as expected, macOS is primarily to blame here I believe.
For my example of moving files, I had a look in Wireshark and though I don't really know much about the SMB protocol, I think the names of the requests make it somewhat clear what's going on and why it's taking so long. So, to move one file from test/1000 to test2/1000 while Finder has the test folder open, macOS asks TrueNAS/samba to do all of the following.
Not sure what a single file move should look like in Wireshark, but it really seems like item #36 is all that should be required. However, it makes tons of requests to search for files and get their information from the directories containing thousands of files so that presumably macOS can do its own error checking. When doing this for many files at once, it interleaves these requests, which makes it pretty obvious why smbd is dying (especially the ones asking for pattern *, which return 70kB of data; the rest should boil down to a single stat() syscall). Each SMB2_FIND_ID_BOTH_DIRECTORY_INFO request has the "restart scans" flag set. Not sure what that means but it sounds like it might have something to do with preventing cached results.
Additionally, when you have a directory containing image or audio files, it will try to read from the files visible in the Finder window to load thumbnail information.
When Finder isn't watching the folder, there are about half as many requests, still including tons of requests for metadata.
What's weird is macOS can in some instances handle directories containing huge numbers of files over SMB shares. I just checked and one of my Time Machine sparse bundles has over 400,000 band files in one directory on the same TrueNAS share, which, through internal Time Machine magic, is handled just fine.
I suspect this problem could be addressed via some kind of caching or modification to the way samba handles requests for fruity clients but it doesn't sound like anyone has figured out how to fully fix the performance issues yet (though there were some mentions of a newer samba version being better?).
I had a dumb idea last night since someone said macOS client <-> macOS server works much better. Just virtualize a macOS machine on the same box as TrueNAS, connect them via iSCSI or something, then have macOS be the SMB server. I'm sure there would be no problems with this configuration whatsoever, especially given how easy it is to virtualize macOS...
drive.google.com
