[Samba] Mac OS Mavericks über slow

[Dan Mons]

We did use Netatalk for a while, but found it didn't scale well to
larger networks.  Samba + vfx_streams_xattr gave us much better
performance as we scaled upwards.

-Dan

----------------
Dan Mons
Unbreaker of broken things
Cutting Edge
http://cuttingedge.com.au


On 4 September 2014 06:47, Ryan Bair <ryandbair at gmail.com> wrote:
> 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
>
>