Re: [2.6.39] CIFS write failures where 2.6.38 works
From: Jeff Layton
Date: Wed Jun 22 2011 - 16:36:27 EST
On Thu, 9 Jun 2011 18:28:45 -0400
Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Fri, 03 Jun 2011 17:11:05 +0200
> Helge Hafting <helge.hafting@xxxxxxx> wrote:
> > On 03. juni 2011 12:15, Suresh Jayaraman wrote:
> > > [Cc linux-cifs@xxxxxxxxxxxxxxx]
> > >
> > > On 06/01/2011 03:41 PM, Helge Hafting wrote:
> > >> At work I use cifs for accessing a windows server. This has worked fine
> > >> for a long time, up to and including Debian's 2.6.38-2.
> > >>
> > >> I just installed Debians's 2.6.39-1, and had to give up on it.
> > >> Mounting CIFS works, and I can see the files. But if I
> > >> try to make a new file (with cp), I get a long delay.
> > >
> > > What is the security mechanism you are using? If you seeing the problem
> > > with ntlm, could you try using ntlmv2 and see whether the problem is
> > > reproducible?
> > In the beginning, I did not specify the mechanism. So, whatever the
> > default is.
> > The fstab entry was like this:
> > \\servername\resource /mountpoint cifs
> > domain=MYDOMAIN,credentials=/etc/fstabcred,rw,noauto,iocharset=utf8,uid=username,gid=group,sockopt=TCP_NODELAY,users,file_mode=0640,dir_mode=0750,relatime
> > 0 0
> > I looked at cifs options, and tried to add "sign" and "sec=ntlmv2i". It
> > made no difference. Still failure with 2.6.39, and mounting with these
> > new options works fine with 2.6.38
> I think we need to understand what's happening on the wire. Are you
> still able to reproduce this? If so, can you turn up debug logging and
> reproduce this?. Instructions for how to do that are here:
> Also, it looks like someone opened a bug at kernel.org too:
> ...so if you can attach the resulting log there, that would be great.
I think that this is probably due to the change that added the
page_mkwrite function to cifs.ko. Prior to that, cifs did single-page
writes on signed connections. Now we do multi-page writes and windows
servers apparently reject large write calls on signed connections.
One way to test this theory would be to set the wsize to something
smaller when you mount. For instance:
...assuming that doesn't go over the server's MaxBufferSize, then that
should act as a workaround. Can you try that and let me know if it
Jeff Layton <jlayton@xxxxxxxxxx>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/