# [OmniOS-discuss] SMB and Netatalk

Chris Ferebee cf at ferebee.net
Thu Feb 16 11:47:20 UTC 2017

- Previous message: [OmniOS-discuss] SMB and Netatalk
- Next message: [OmniOS-discuss] SMB and Netatalk
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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

- Previous message: [OmniOS-discuss] SMB and Netatalk
- Next message: [OmniOS-discuss] SMB and Netatalk
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list