Are there any limits imposed on SMB shares?

[vitaprimo]

I moved my iTunes library from another file server to Unraid.

 

Instead of using the existing database though, I'm creating a new one. The files are already in place since it's a copy of the top level directory, I'm only scrapping the database file for a new one so there should be minimal disk activity had stray files were found in need of reorganization.

 

With the new library created, I started the scan on iTunes to add the files on the new library but it found 300 tracks.  That's tracks, not files. With metadata files it should be plenty more of what was found, but then again the metadata files of the total would be much, much bigger too. I neglected for streaming services and entrusted it to iTunes Match, so I have no idea how big is supposed to be but I remember that even after all of the lost data it was somewhere around 14K.

 

That's plenty more than 300.

 

I did another scan and the number was raised to 500+. On the third scan it was raised to 6 tracks to 700. In other words, the files are there but when I do the scans it seems to only find small batches at a time.

 

Before being hosted in Unraid, the library was read form another SMB file share, it had (and still is) been hosted there for like a decade, re-scanned a few times too over the network without issues on the early days of SMB3 as well as later on and, it's stable Active Directory environment. I can even request Kerberos tickets from Unraid, I accidentally found out the other day thinking I was logged in somewhere else.

 

I've hosted the same library in Red Hat Enterprise Linux, Debian, Synology's DSM, FreeNAS+TrueNAS, macOS Server and Windows Server and this is the first time I see this behavior at the same time I'm actually ignorant on the actual manual setup of SMB shares as all of these platforms have a specialized easy GUI to do it (that's Cockpit or Webmin on RHEL+Deb) and on the past I've always used Unraid as an app- never file server.

 

So I'm unaware if I should've set some tunable adjustment and overlooked it.

 

Setup and testing

 

The array is an all-flash pool with only user shares distributed using the most free file-to-disk allocation scheme. I figured that would behave somewhat like a RAID0 or JBOB thus offering the least disk contingency. The server is basically dedicated to my iTunes library, so the files are small but not so small that's a burden in resources.

 

I checked on my client, the iTunes host; a macOS machine that's still able to run iTunes. It's a server system so it already has some optimizations, nevertheless I rechecked some basics, like not writing dot files, confirm disabled access times, limit SMB to SMB3, disable packet encryption and packet signing and of course requesting fresh Kerberos tickets on both systems before doing library re-scans.

 

The most telling test was when I unmounted the share and remounted it using the NFS protocol. After a re-scan it found all remaining files. Now I just hope it's not unreliable as just before the server stopped responding out of the blue requiring to be cold reset each time.

 

Any advice is welcome.

 

[itimpi]

There should be no limits via SMB that I am aware of.  I have some shares that have millions of files and that are accessed over SMB without problems.

 

in terms of allocation methods, the Most Free allocation scheme tends to be the least efficient as it tends to scatter files across drives keeping them all spun up..   The default of high-water is better at keeping related files on the same drive and providing a better balance than the fill-up one.   The aim is to improve the chances of drives not being used being spun down to save power.