[OmniOS-discuss] SMB and Netatalk

[Dan Vatca]

Hi,

This issue is caused indeed by the calls to getcwd that are very slow on illumos/solaris. A workaround that solves the performance problems is to avoid those calls entirely by setting “follow symlinks = yes”.
However, this will allow server-side symlinks to be followed outside the directory.
If permissions are setup correctly, it should not be that big of a security issue.

Dan.

On 16/02/2017, 13:47, "OmniOS-discuss on behalf of Chris Ferebee" <omnios-discuss-bounces at lists.omniti.com on behalf of cf at ferebee.net> wrote:

    Hi Fabio,
    
    Let me tell you about my personal hell. In 2014 I tried to set up a big file server for a motion graphics client using netatalk on SmartOS.
    
    To put it succinctly, it was a disaster. The Finder took forever to open windows on the server, etc.
    
    With help from people who actually know what they’re doing (unlike me) I reached the following conclusions.
    
    The Finder, starting around 10.7 or 10.8, behaves very poorly with shares under certain circumstances. If any folder window is open in the Finder, it will continually thrash through the subdirectories doing
    
    	fsgetpath()
    	getxattr()
    	getattrlist()
    
    on everything. I think this is a Finder bug, and it seems to be present in macOS Sierra as well.
    
    Samba replies to these queries from a cache, but netatalk performs calls to getcwd() [get current working directory] for every call to fsgetpath. This call is very expensive on Solaris - the OS doesn’t cache it because there is no expectation that it will be called frequently.
    
    As a result, the Finder on a single Mac client, sitting idle with one folder window open to the netatalk share, would peg a core on the server. It would take tens of seconds, sometimes minutes, to display the contents of folders. (I’m sure it didn’t help that we had over 100 million files on the share.)
    
    Take a look at this thread, where we discuss the issues.
    
    	<https://sourceforge.net/p/netatalk/mailman/message/32660961/>
    
    At some point Ralph Böhme seemed to suggest that this Finder behaviour could be avoided if netatalk were built with full Spotlight API support, but that was too experimental at the time for me to attempt in production. That may be why this issue doesn’t seem to affect AFP connections to Apple’s afp server.
    
    In the end, we switched from netatalk to HELIOS EtherShare, which is $$$, but has been rock-solid and blazingly fast.
    
    Note that this problem seems to affect netatalk on Linux to a lesser degree, perhaps because getcwd() is much faster on Linux than on Solaris.
    
    Best,
    Chris
    
    
    > Am 15.02.2017 um 18:16 schrieb Fábio Rabelo <fabio at fabiorabelo.wiki.br>:
    > 
    > Hi to all
    > 
    > There are someone with experience in running SMB and/or Netatalk over OmniOS ?
    > 
    > Works OK ?
    > 
    > Some caveats to avoid ?
    > 
    > The possible scenario would be a server to hold Audio and Video files
    > in a Video/Audio editing facility, with 10 GB network in/out, and 12 8
    > TB hard disks in Raid Z2, 2 256GB SSD to ZIL, no ARC, 128 GB RAM .
    > 
    > Thanks in advance ...
    > 
    > 
    > Fábio Rabelo
    > _______________________________________________
    > OmniOS-discuss mailing list
    > OmniOS-discuss at lists.omniti.com
    > http://lists.omniti.com/mailman/listinfo/omnios-discuss
    
    _______________________________________________
    OmniOS-discuss mailing list
    OmniOS-discuss at lists.omniti.com
    http://lists.omniti.com/mailman/listinfo/omnios-discuss