On Wed, 12 Oct 2011 14:06:13 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Wed, Oct 12, 2011 at 12:25 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 12 Oct 2011 12:15:29 -0500 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > >> Reviewing changes to fs/cifs/connect.c in > >> http://git.samba.org/?p=jlayton/linux.git;a=commit;h=b82a25501cb18b86fd247da15c886762fdc5404c > >> > >> It looks like the following logic changes from setting rsize to what > >> the server claims it can support (negotiated maxBuf) to what our > >> maximum buffer size is: > >> > >> @@ -3130,8 +3130,7 @@ try_mount_again: > >> cFYI(DBG2, "no very large read support, rsize now 127K"); > >> } > >> if (!(tcon->ses->capabilities & CAP_LARGE_READ_X)) > >> - cifs_sb->rsize = min(cifs_sb->rsize, > >> - (tcon->ses->server->maxBuf - MAX_CIFS_HDR_SIZE)); > >> + cifs_sb->rsize = min(cifs_sb->rsize, CIFSMaxBufSize); > >> > >> > >> Is that what we want? > >> > > > > I think so, yes. That's part of untangling the mess. > > > > According to the protocol docs, the server should only be bound by the > > client's MaxBufSize for reads. Therefore, the maxBuf advertised by the > > server should have no bearing on the rsize. > > That may be true, but the following phrase in the description of > SMB Read (not ReadX) worried me: > > "If a read requests more data than can be placed in a message of > MaxBufferSize for the SMB > connection, the server MUST abort the connection to the client." > I don't think that cifs.ko ever does old-school SMB Read calls, does it? We don't seem to even have the command defined in cifspdu.h... Regardless, that code will go away once you get to this patch: cifs: allow for larger rsize= options and change defaults I wouldn't sweat it too much. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
