[lkml]   [2009]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.31-rc8: CIFS with 5 seconds hiccups
    On Thu, 10 Sep 2009 14:53:12 -0400 (EDT)
    Christoph Lameter <> 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?

    Jeff Layton <>

     \ /
      Last update: 2009-09-10 21:37    [W:0.039 / U:6.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site