[Samba] Fruit/AAPL behavior

[Ralph Boehme]

Hi Ryan

On Mon, Feb 01, 2016 at 01:24:45PM -0500, Ryan Bair wrote:
> On Fri, Jan 29, 2016 at 11:09 AM, Ralph Boehme <rb at sernet.de> wrote:
> > On Thu, Jan 28, 2016 at 10:40:32PM -0500, Ryan Bair wrote:
> > > I have a share with approximately 5000 folders in the base directory. The
> > > performance on an OS X client is somewhat less than exciting. I compiled
> > > the latest Samba 4.3 tarball and enabled fruit per the modules man page,
> > > however directory listing performance still takes a few seconds.
> >
> > sounds reasonable for 5000 elements in a folder. How long does it take
> > without fruit?
> >
> 
> Around 30 seconds.

so a huge speedup, cool! :)

> > > In wireshark I'm still seeing a GetInfo Request for every file and
> > > directory which hammers my poor server.
> >
> > Possibly, but the client should already display the folder content
> > after doing the initial find.
> >
> 
> True, initial listing is _way_ faster with fruit.
> 
> I've found that subsequent file operations (such as opening a child
> directory) are usually blocked until Finder has finished looking up the
> metadata for all the items in the parent.

Yeah, that's just insane Finder behaviour regardless of protocol, iirc
I analyzed the same issue with AFP/Netatalk.

> I'm guessing this is because the users smbd process is stuck
> spinning at 100% CPU and the new request is stuck at the back of the
> queue.

Not quite, the queue that gets blocked is the client request queue,
because the Finder doesn't cancel pending *unsent* requests when a
Finder window is closed.

> > > I was under the impression the aapl protocol extension was supposed
> > > to make these requests unnecessary. Am I misunderstanding the
> > > functionality or is something wrong?
> >
> > Slightly inaccurate. It will still make the requests (the exact
> > behaviour depends on OS/Finder version), but should display folder
> > content after initial find, because the find response is enriched with
> > the Apple relevant metadata (FinderInfo, resource fork lenght,
> > effective permissions).
> >
> 
> Ah, understood. Netatalk still has a decent lead on overall load time and
> server impact

yes, Netatalk is just a thin layer on top of POSIX, Samba is a
different beast.

> since the client batches the look ups (40 per request IIRC).

AFP doesn't batch anything and directory enumeration actually requires
more roundtrips compared to SMB, as AFP directory enumeration is only
40 (or 64) directory entries per roundtrip.

> Would it be possible (or sensible) for fruit to ignore Samba's usual case
> insensitivity semantics for resource fork look ups?

That's basicallly the case with fruit, as fruit looks up the resource
fork in a private function that iirc bypasses Samba's case sensitivity
abstractions.

> While that would not reduce the number of requests, it would reduce
> the cost per request quite significantly.

You can try something else, cf man vfs_fruit:

readdir_attr:aapl_max_access = false

Disables expensive effective permissions calculation which may not be
needed depending on your setup.

-Ralph

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