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.
I've cranked the fruit debug level up to 10 and can see that it is getting
used ("fruit_stat called for files", for instance). I've also
looked
through Wireshark and it appears to appropriately negotiate the AAPL
extension with the client.
In wireshark I'm still seeing a GetInfo Request for every file and
directory which hammers my poor server. 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?
The details:
Server: CentOS 6
Samba 4.3.4
Client: OS X 10.9.5
smb.conf:
[global]
workgroup = EXAMPLE
realm = ad.example.com
netbios name = SERVER
server role = active directory domain controller
wins support = yes
idmap_ldb:use rfc2307 = yes
winbind nss info = rfc2307
winbind expand groups = 10
template shell = /bin/sh
dns forwarder = 192.168.1.1
log level = 0 vfs:10 fruit:10
unix extensions = no
tls enabled = yes
tls keyfile = tls/server_AD_DC.key
tls certfile = tls/server_AD_DC.crt
tls cafile = tls/home_CA.crt
vfs objects = catia fruit streams_xattr
[netlogon]
path = /var/lib/samba/sysvol/ad.example.com/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[Share]
path = /srv/share
read only = no
Thanks
Hi, 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? You may be able to squeeze some more out of it by adding: readdir_attr:aapl_max_access = false This results in the clients incorrect view of effective permissions though, but if everything is eg 0777 anyway than why care?> I've cranked the fruit debug level up to 10 and can see that it is getting > used ("fruit_stat called for files", for instance). I've also looked > through Wireshark and it appears to appropriately negotiate the AAPL > extension with the client. > > 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.> 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). -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 at sernet.de
Hi Ralph, Thanks for the reply and thank you for your work on vfs_fruit. On Fri, Jan 29, 2016 at 11:09 AM, Ralph Boehme <rb at sernet.de> wrote:> Hi, > > 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.> > 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. 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. I've had a few times where OS X drops the server connection, presumably because the 2nd operation took too long to complete.> > > 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 since the client batches the look ups (40 per request IIRC). Would it be possible (or sensible) for fruit to ignore Samba's usual case insensitivity semantics for resource fork look ups? While that would not reduce the number of requests, it would reduce the cost per request quite significantly.> > -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 at sernet.de >