[Samba] vfs_fruit causes delay in listing directories for Windows clients
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
> "fruit:metadata = stream" would get rid of this. Check your setup
> carefully to decide which mode you need.
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