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." -- Thanks, Steve -- 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
