3 ms·

FYI, macOS Finder SMB perf is just fine as long as you connect to the SMB share by its IP address (i.e. by typing “smb://10.0.1.1” in the Cmd+K dialog.) It’s o

by derefr 3y ago

FYI, macOS Finder SMB perf is just fine as long as you connect to the SMB share by its IP address (i.e. by typing “smb://10.0.1.1” in the Cmd+K dialog.) It’s only when you connect to an SMB share by name (incl. by browsing to the share in the Network view) that things get hinky.

bravetraveler 3y ago
It considers '/etc/hosts' when resolving names, right? I wonder if putting the name/IP in there makes it closer to equal - primitive cache
VHRanger 3y ago
Wtf! I've never known that! Of course I have anyone connecting to SMB://fileserver to make it convenient and stable across router reboots. I didn't expect naming it to be an issue.
- derefr 3y ago
  I think the Finder — or discoveryd underneath — is doing some kind of non-cached(!) WINS name lookup for each fopen(2) syscall against SMB shares mounted through their WINS name. If your SMB server is running Linux, IIRC (this was ~8 years ago, so this might no longer be true) that it also seemed to work, to run avahi on the Linux host, configured to announce the system the way you would if you were setting up AFP on the host; and to have avahi then announce SMB as a service (mDNS SRV record) for the system. I'd recommend trying to find an old guide for setting up a Linux AFP server. You don't actually have to set up (or even install) AFP, though; just do all the avahi parts! Why does this work? I think it's because, unlike for the WINS names underlying SMB, macOS seems to have an optimized and cached name-lookup path within discoveryd for the mDNS SRV records that would underlie AFP shares. And this code-path seems to be perfectly happy with discovering an SMB share via mDNS. (Probably because of some legacy transition Apple went through internally, where AFP shares were deprecated + replaced with SMB shares, while still being published "as if they were" AFP shares, via mDNS.)

by derefr 3y ago

bravetraveler 3y ago

It considers '/etc/hosts' when resolving names, right? I wonder if putting the name/IP in there makes it closer to equal - primitive cache

VHRanger 3y ago

Wtf! I've never known that! Of course I have anyone connecting to SMB://fileserver to make it convenient and stable across router reboots. I didn't expect naming it to be an issue.

derefr 3y ago
I think the Finder — or discoveryd underneath — is doing some kind of non-cached(!) WINS name lookup for each fopen(2) syscall against SMB shares mounted through their WINS name. If your SMB server is running Linux, IIRC (this was ~8 years ago, so this might no longer be true) that it also seemed to work, to run avahi on the Linux host, configured to announce the system the way you would if you were setting up AFP on the host; and to have avahi then announce SMB as a service (mDNS SRV record) for the system. I'd recommend trying to find an old guide for setting up a Linux AFP server. You don't actually have to set up (or even install) AFP, though; just do all the avahi parts! Why does this work? I think it's because, unlike for the WINS names underlying SMB, macOS seems to have an optimized and cached name-lookup path within discoveryd for the mDNS SRV records that would underlie AFP shares. And this code-path seems to be perfectly happy with discovering an SMB share via mDNS. (Probably because of some legacy transition Apple went through internally, where AFP shares were deprecated + replaced with SMB shares, while still being published "as if they were" AFP shares, via mDNS.)