[Samba] Mac OS Mavericks über slow

Ralph Böhme rb at sernet.de
Thu Sep 4 07:17:13 MDT 2014


Hi

On Wed, Sep 03, 2014 at 10:17:10AM +1000, Dan Mons wrote:
> The problem is MacOSX's Finder requiring lookups of resource forks
> files.

To be precise: metadata *and* resource fork, both packed together in a
single AppleDouble [1] file.

> 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.

Certain applications on Macs still rely on metadata and resource fork
information, so depending on application and workflow one has to be
careful when switching file sharing protocols and options.

> 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.

Additionally a NACK is expansive by default in Samba itself (it goes
out and does a *full* *rescan* of the *whole* directory doing a case
insensitive filename comparison).

> It's also the reason why slow links like VPN or WAN
> users find the problem compounds for them.

It's actually slightly different for WAN access (high network
latency), which means enabling named streams support (eg using
vfs_streams_xattr) doesn't help.

Without named streams support (ie without vfs_streams_xattr, vfs_fruit
or vfs_depot) this is what happens:

Opening a folder with 1000 files in Finder (n=1000)
===================================================

1. User opens folder
2. Kernel SMB2 client issues smb2_find command requesting directory
   listing of folder
3. Samba server returns all 1000 directory entry in one big swoop (by
   contrast AFP does a max of 64 entries per roundtrip). The entries
   already carry a certain set of filesystem metadata, alas they lack
   the size info an associated resource fork (0 if none exists). So as
   the Finder requested this information:
4. The client *sequentially* issues 1000 smb2 requents checking for ._
   files
5. Once the client has the replies, the Finder displays the folder
   content

There are two things that make step 2 potentially dead slow:
a) network latency (network latency in ms * n)
b) Samba rescanning the directory n times

Now by enabling named streams support in Samba you get rid of b), not a):

Opening a folder with 1000 files in Finder with named streams support
=====================================================================

1. User opens folder
2. Kernel SMB2 client issues smb2_find command requesting directory
   listing of folder
3. Samba server returns all 1000 directory entry in one big swoop (by
   contrast AFP does a max of 64 entries per roundtrip). The entries
   already carry a certain set of filesystem metadata, alas they lack
   the size info an associated resource fork (0 if none exists). So as
   the Finder requested this information:
4. The client *sequentially* issues 1000 smb2 requests checking named
   streams info
5. Once the client has the replies, the Finder displays the folder
   content

You see that only step 4 is different from above, but this already
helps a lot given that checking xattr information on a file is fast in
the filesystem.

It doesn't help if you're network latency is high, because you still
have to wait n * network latency ms for the Finder to display the
folder contents!

Is there a way to improve this? You bet there is! ;)

Apple uses a custom smb2 protocol extension in its own server (and
client): a smb2 create context "AAPL". If both server and client
support this it, the smb2_find reply (amongst other things depending
on a set of flags [2]) is modified to contain resource fork size
information, which means after step 2 (see above) is completed, the
Finder will display the folder content.

I have a working PoC here: [3]. Opening a folder with 1000 files over
a slow link with 50 ms latency takes just a few seconds instead of 40
seconds with just vfs_streams_xattr or vfs_fruit alone.

This is still incomplete and needs more polishing.

> 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).

Just beware that most filesystem limit the maximum size of xattrs
(iirc 64 KB per xattr on XFS) which completely breaks applications
making use of larger resource forks (eg Adobe Photoshop, Postscript
Type 1 fonts).

Samba 4.2 will ship a new VFS module that addresses this:
vfs_fruit. It stacks with vfs_streams_xattr but takes care of the
resource fork stream itself (on Linux: by saving it to a ._
AppleDouble file).

Cheerio!
-Ralph

[1] <http://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats>
[2] <https://github.com/slowfranklin/apple-smb2/blob/master/kernel/netsmb/smb_2.h#L138>
[3] <https://github.com/slowfranklin/samba/commits/aapl>

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt@sernet.de


More information about the samba mailing list