[Samba] vfs_fruit causes delay in listing directories for Windows clients

Stephan Roth stroth at ee.ethz.ch
Mon Dec 17 07:46:33 UTC 2018

On 12.12.2018 16:54, Ralph Böhme via samba wrote:
> On Wed, Dec 12, 2018 at 04:37:43PM +0100, Ralph Böhme via samba wrote:
>> On Wed, Dec 12, 2018 at 03:35:00PM +0100, Stephan Roth via samba wrote:
>>> My goal with activating vfs_fruit was to speed up directory listings 
>>> for Mac clients, which works. Can the accompanying slowdown for 
>>> Windows clients be avoided?
>> yeah, I guess so, but somebody has to dig through the relevant 
>> codepaths for a few days to implement the optimisations.
> thinking about it, most codepaths already do avoid special processing if 
> not in AAPL mode or when not operating on a stream.
> There's one exception however: fetching the file creation date from 
> Netatalk metadata when in "fruit:metadata = netatalk" mode which is the 
> default.
> "fruit:metadata = stream" would get rid of this. Check your setup 
> carefully to decide which mode you need.
> -slow

Thank you Ralph, that helped.

To sum up what I observed:

stracing the listing of a directory with vfs_fruit activated on the 
share containing the directory and "fruit:metadata = netatalk shows 
three additional function calls per file in the directory in comparison 
to listing a directory on a share without vfs_fruit:

stat, getxattr, listxattr

Changing this to "fruit:metadata = stream" eliminates the getxattr call, 
stat and listxattr remain.

The time to answer these calls differs depending on the underlying file 
system. On plain ext4 I observed around 0.000015 s per call, on the 
setup I'm interested in with BeeGFS its 0.00033 s. And the latter is 
noticeable to end users when they list a directory on a Windows client.

Let me know if you want me to open a bug about this behaviour.


More information about the samba mailing list