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-boun...@lists.omniti.com on behalf of c...@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 <fa...@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@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
