On Thu, 10 Sep 2009 14:53:12 -0400 (EDT) Christoph Lameter <[email protected]> wrote:
> On Wed, 9 Sep 2009, Jeff Layton wrote: > > > Well, I can see the delays in the capture, but the snarflen for the > > capture is a little too small to tell much else. Can you redo the > > capture with a larger snarflen (maybe -s 512 or so)? > > -s 1000 version attached. > > > Also, were you able to tell anything from a server-side capture? Is the > > server issuing oplock breaks at those times? > > Thats a pretty busy system. They have not gotten around to do any logging > on that end. Ok. I had a look at the capture. The stalls seem to be occurring on FIND_FILE requests. Those are similar to READDIRPLUS requests in NFS, it returns a list of files that match a particular set of criteria and their attributes. Each time the client is making one of these calls to the server, it requests a set of up to 150 files. The server grinds for 5s each time and then responds. The calls themselves seem to be sane AFAICT. I don't see any problems with the parameters we're sending for the search. I also had a look over the FIND_FIRST code and it doesn't seem to have any obvious word size related problems. I assume that the 32 and 64 bit clients you have are calling "ls" in the same dir. If so, maybe a similar capture from a 64-bit client might help us see the difference? Thanks, -- Jeff Layton <[email protected]> -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
