Re: 2.6.31-rc8: CIFS with 5 seconds hiccups

Jeff Layton <[email protected]>
Newsgroups gmane.linux.file-systems.cifs,gmane.network.samba.general,gmane.linux.kernel
Message-ID <[email protected]>
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]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.