Re: [Samba] vfs_fruit causes delay in listing directories for Windows clients
- Date: Mon, 17 Dec 2018 08:46:33 +0100
- From: Stephan Roth via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] vfs_fruit causes delay in listing directories for Windows clients
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.
To unsubscribe from this list go to the following URL and read the