> 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://gluster.org/pipermail/gluster-users/attachments/20110718/4003848a/attachment.htm>
