[OmniOS-discuss] Best way to share files with Mac?

[Geoff Nordli]

Hi Chris.

I wonder if now this is fixed with the vfs_fruit module in Samba.

http://plazko.io/apple-osx-finder-is-listing-files-very-very-slow-when-connected-to-smb-shared-hard-drive-connected-to-a-wifi-router/

thanks,

Geoff



On 2017-11-25 06:45 AM, Chris Ferebee wrote:
> Hi Geoff,
>
> I love the way you put this:
>
>> They are reporting problems with the speed when using the "finder".
> Oh, yes. I spent months of my life in 2014 fighting the Finder vs. a major installation of netatalk, which I deployed on SmartOS.
>
> We have a large server (dual 6-core XEON, 128 GB RAM, 22 x 4 TB SAS, STEC ZeusRAM) running as a fileserver for Macs. The client does motion graphics and has a very large number of files, 100+ million on the largest share. (Not more than a few thousand files per directory, though.)
>
> What we saw was that opening the Finder to a directory on the AFP share would show a blank window for 20–180 seconds before displaying the contents, even if there were maybe just 10–20 subdirectories to display.
>
> Then, as long as the Finder window was open, it would peg one CPU core on the server at 100%, even though the display did not change.
>
> It turned out that the Finder was looping continually through files several subdirectories deep, querying extended attributes. Due to the way netatalk is coded, this requires a call to getcwd() each time, which is very expensive on Solaris. (getcwd() = get the path name of the current working directory.)
>
> A SmartOS engineer was kind enough to advise me on this, and basically told me: if you have getcwd() in your hot path, you are screwed. This is probably a reason why the problem, though actually a netatalk issue, is less pronounced on Linux, where getcwd() is not as expensive as on Solaris.
>
> I never did get to the bottom of this. It appears that it doesn’t happen when the Finder is talking to Apple’s own AFP server, perhaps because there the Finder is able to use FSEvents to track changes. Unfortunately, it appears that netatalk has never fully addressed this, at least I haven’t seen anything indicating that it has gained FSEvents supports in the past years. Here is what netatalk dev Ralph Böhme had to say:
>
> 	<https://sourceforge.net/p/netatalk/mailman/message/32669188/>
>
> In the end, I switched the client to a (commercial, expensive) AFP server, HELIOS EtherShare, and all problems went away, performance as expected, and I didn’t investigate further.
>
> If you are dealing with Adobe applications, be aware that there are a number of reasons why they do not work well on a Mac over SMB. We didn’t get past a hard maximum path length of 254 characters, but there are others.
>
> I’m happy to discuss this further, and would be quite interested to find a less-expensive solution for large-scale file service for Macs. We can take it off-list if it goes any further off topic.
>
> Good luck,
> Chris
>
>
>> Am 24.11.2017 um 03:56 schrieb Geoff Nordli <geoffn at gnaa.net>:
>>
>> Hi.
>>
>> I have to support a few mac machines connecting to a few file shares running Omnios.
>>
>> They are reporting problems with the speed when using the "finder".
>>
>> I see there is a netatalk package I can download and compile off of sourceforge, which looks fairly current.
>>
>> Any suggestions on the best way forward to support Mac machines?
>>
>> thanks,
>>
>> Geoff
>>
>>