I can’t figure out where my bottleneck/issues are with accessing shares on my Mac.

 

My Unraid specs are as follows:

• Intel® Xeon® CPU E3-1225 v3 @ 3.20GHz
• LENOVO ThinkServer TS140 (Moved motherboard to a different case)
• LSI 6Gbps SAS HBA LSI 9211-8i
• IBM ServeRAID 16-Port 6Gbps SAS-2 SATA Expansion Adapter
• Plugable 2.5G USB C and USB to Ethernet Adapter
• Unraid 6.11.1 (updated drivers to work with 2.5G USB)

 

Using the “SpeedTest-By-OpenSpeedTest” my network speed comes in around 2300 Mbps or around 287.5 MBps so that’s my theoretical max speed

 

I’m using “Blackmagicdesign Disk Speed Test” to test local and share speeds.

 

Running my SSD drive locally I can get 465 MBps / 375 MBps read/write

 

I’m only trying to troubleshoot caching speeds, I understand reading/writing directly to the array is a different story. Unless I’m mistaken, writing to a share that is using the cache should not have any overhead, correct?

 

I made a “cache only” share so only the cache speed is tested.

 

I go back and forth between using NFS shares and SMB shares.

 

Sometimes SMB is faster but it’s VERY inconsistent and overall is less stable (Finder will crash/hang) and file browsing is VERY slow.

I’ve had a test speed one time of 252/197.4 read/write but right now I’m only getting 190/152 and earlier I was only getting like 50/30 and sometimes ever slower.

 

Ultimately it doesn’t matter what the speed is on SMB shares… they are effectively unusable because of the slow browsing speeds and constantly crashing the Finder.

 

With NFS on the other hand I can browse folders and files pretty much instantly.

 

The speeds are very consistent when connecting to a share. I almost always get 175/90 read/write.

What is very odd is if I take the same SSD and remove it from the cache and just share it as an unassigned drive I get less consistent speeds.I recently got 191/176 but right now I’m getting 171/167. So I can get higher than the 90 writes over NFS but no idea why that’s only when it’s not part of the array.

There is some discussion of optimizing macOS performance here.

If that doesn’t help post a screenshot of settings>smb.

Also the contents of boot/config/fruit-smb.conf.

1 hour ago, wgstarks said:

There is some discussion of optimizing macOS performance here.

If that doesn’t help post a screenshot of settings>smb.

Also the contents of boot/config/fruit-smb.conf.

 

Yea, I've tried tweaking the SMB fruit settings ad nauseam, it's frustrating to see yet another release version and yet another thread that just basically says here are some settings you can randomly try, good luck!

 

My smb-fruit.conf is as follows

 

# global parameters are defined in /etc/samba/smb.conf
# current per-share Unraid OS defaults
vfs objects = catia fruit streams_xattr
#fruit:resource = file
#fruit:metadata = netatalk
#fruit:locking = none
#fruit:encoding = private
fruit:encoding = native
#fruit:veto_appledouble = yes
#fruit:posix_rename = yes
#readdir_attr:aapl_rsize = yes
#readdir_attr:aapl_finder_info = yes
#readdir_attr:aapl_max_access = yes
#fruit:wipe_intentionally_left_blank_rfork = no
#fruit:delete_empty_adfiles = no
#fruit:zero_file_id = no
# these are added automatically if TimeMachine enabled for a share:
#fruit:time machine

 

 

 

I don’t know that it’ll make much difference but I have a few settings different.

fruit:metadata = stream
fruit:posix_rename = yes

 

Any changes with 6.12 on this? 

 

I moved over to NFS a long while back and now even that's not working. It'll freeze up the finder opening a subfolder with a dozen or so files.

I have no issues with SMB if I host shares from a Windows machine or a RasPi.  Fast, near-instant updated file lists and stable. With unraid, shares are pretty much unusable from MacOS now.

Edited June 27, 20233 yr by Espressomatic

Similar issues here. Mounting a SMB Share on my Mac is very slow. Can anyone help?
 

  GNU nano 7.2                                              smb-fruit.conf                                                        
# global parameters are defined in /etc/samba/smb.conf
# current per-share Unraid OS defaults
vfs objects = catia fruit streams_xattr
#fruit:resource = file
#fruit:metadata = netatalk
#fruit:locking = none
#fruit:encoding = private
fruit:encoding = native
#fruit:veto_appledouble = yes
#fruit:posix_rename = yes
#readdir_attr:aapl_rsize = yes
#readdir_attr:aapl_finder_info = yes
#readdir_attr:aapl_max_access = yes
#fruit:wipe_intentionally_left_blank_rfork = no
#fruit:delete_empty_adfiles = no
#fruit:zero_file_id = no
# these are added automatically if TimeMachine enabled for a share:
#fruit:time machine
#fruit:time machine max size = SIZE

 

Are the hashed lines ignored?

FWIW, a ton of testing has gone into shares on Macs (with an emphasis on TM shares) on the latest to be released OS versions (soon).

 

Contrary to what comes up as default on suggestions for accessing shares when googling, you want to keep DS_Store files being written by the Mac on Network Shares.  Disabling them gives a massive delay on initial access to a share or folder within a share that may contain tons of files / directories (subsequent accesses tend to be instantaneous) .  This does however have a caveat.   Drives will tend to spin up when accessing the share / folder, and access may wind up being slower if the user on the Mac does not have write access to the share.

 

From terminal on the Mac 

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool FALSE

and reboot the Mac (I've found that Apple saying to simply log out isn't sufficient).  You *may* need to also delete any pre-existing .DS_Store files that may be present in the share / folder if you're still having issue.  (And if you've set up smb-extra.conf to veto DS_Store files you're going to want to delete those modifications)

 

As an aside, TM shares are also IMO damn near bulletproof and the easiest they've ever been.

 

I'm only one tester, but my experience is now night and day....