[Samba] Mac OS Mavericks über slow

[Ryan Bair]

As others have said resource fork lookup is the problem. Instead of doing
one command to list the directory like Windows, Finder does that plus one
for each entry in the directory leading to a terrible experience.

I've tried DAVE in our shop but saw little to no improvement in that area.
Their support people confirmed the issue and placed the blame on Finder.

We are using Netatalk/AFP with good results. It's still not nearly as fast
as Windows 7 clients with Samba, but usable even with 10,000+ directory
entries.


On Tue, Sep 2, 2014 at 8:17 PM, Dan Mons <dmons at cuttingedge.com.au> wrote:

> The problem is MacOSX's Finder requiring lookups of resource forks
> files.  You see these frequently on your file server - for each
> "file.ext" you'll see a "._file.ext" with resource fork information in
> it - a throwback to ancient times.
>
> MacOSX Finder does a lookup for each of these, which causes a NACK on
> Samba.  This process is slow for folders with many files.  On our
> 100TB GlusterFS setup, it's even worse, as a NACK on clustered storage
> is very slow.  It's also the reason why slow links like VPN or WAN
> users find the problem compounds for them.
>
> The solution we found was to enable streams_xattr:
>
> http://www.samba.org/samba/docs/man/manpages/vfs_streams_xattr.8.html
>
> This allows the resource fork information to be stored on disk inside
> xattr  (extended attributes) instead of a a file, and MacOSX's Finder
> then doesn't require the extra lookup.  You'll need a backing file
> system with xattr enabled (we use XFS under GlusterFS, so this is
> enabled by default for us).
>
> On 3 September 2014 03:12, Emmanuel Florac <eflorac at intellique.com> wrote:
> > Try disabling the unix extensions. Alternatively, NFS works perfectly
> > well with Macs...
>
> I'm sorry, but NFS is awful on MacOSX.  The MacOSX client (in
> partciular Finder and its fscache) has all sorts of problems with NFS
> shares.  Files and folders regularly disappear from view, renaming of
> a file from uppercase to lowercase and back confuses the hell out of
> Finder, and multiple people writing/editing files in the same folder
> causes all sorts of chaos.  MacOSX appears to have two different file
> system caches - one for Cocoa GUI applications (Finder, etc) and one
> for the BSD subsystem and all CLI applications.   We frequently find
> CLI-only tools work OK over NFS, but GUI tools (including launching
> GUI tools from the CLI) have all sorts of dramas.  NFS thus becomes
> completely unusable for our studio on MacOSX, and without a native
> FUSE-GlusterFS that's stable for OSX, we're forced to use SMB.
>
> SMB is only marginally better, but brings it's own set of problems.
> As much as I love MacOSX dearly, it's utterly horrendous to use on a
> network.  It's a fantastic standalone system, and has no problems in a
> cloud-connected world where everything is delivered by HTTP/HTTPS.
> But when it comes to high performance storage protocols like NFS and
> SMB, MacOSX (and in particular Finder) is way down the list of
> usability.
>
> -Dan
>
>
> ----------------
> Dan Mons
> Unbreaker of broken things
> Cutting Edge
> http://cuttingedge.com.au
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>