[Gluster-users] not sure how to troubleshoot SMB / CIFS overload when using GlusterFS

[Anand Avati]

> I also took your advice last night on stat-cache (I assume that was on the
> Gluster side, which I enabled), and wasn't sure where fast lookups was.
> That didn't seem to make a noticeable difference either.
>

stat-prefetch xlator does not help here. It helps quicken lookups. But Samba
is not interested in lookup/attributes. It is only looking for existance of
directory entry names, without caring whether it is a file or directory.


>
> I think the lockups are happening as a result of being crippled by
> GlusterFS's relatively slow directory listing (5x-10x slower generating a
> dir listing than a raw SMB share), combined with FUSE's blocking readdir().
> I'm not positive on that last point since there was only one mention of that
> on the internet.   Am praying that somebody will see this and say, "oh yeah,
> well sure, just change this one thing in FUSE and you're good to go!"
> Somehow I don't think that's going to happen.  :)
>
>
GlusterFS uses readdirp() internally even if FUSE asks readdir() because it
makes generation of unique list of entry names in distribute much more
efficient and simple. This might be causing readdir ops themselves to be
slow. Doing an 'strace -Tc' on smbd can show you what %age of time is spent
in getdents().

One test you could try is checking if a pure replicated setup without
stat-prefetch has the same performance hit as a distributed(+replicated?)
setup? Both stat-prefetch and distributed "upgrade" readdirs into readdirps
(one for performance, another for unique list generation).

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20110718/4003848a/attachment.html>