On Thu, Mar 01, 2012 at 01:37:47PM -0500, Jeff Layton wrote: > > (cc'ing Chris and Jeremy to make sure I understand) > > The description above is a good start but doesn't quite outline the > clear concise "rules" for this that I was looking for. > > So if I understand what Steve wrote above, he's basically saying that > we should enforce the maxmpx for everything but blocking locks and > echoes? Is that correct? If so then I think that's wrong and won't fix > any of the problems that people have reported with the existing code. > > It's all well and good that *some* servers allow you to exceed the > maxmpx in *some* cases, but we can't code to that assumption. We know > well that many servers do not handle exceeding the maxmpx gracefully at > all. As always we have to code to the lowest common denominator by > default, and then optionally allow people to exceed that if they choose > to do so. > > I think this is a case where we need a good description in a human > language (preferably english) of how this should work (aka a > specification), and then write code to match that description (aka code > to the spec). > > Anything else is going to send us down the rabbit hole where we are > today with cifs.ko -- a bunch of ad-hoc, broken code that no one really > understands. > > While we may not like it, a hard cap on the number of outstanding > requests is required by the protocol docs that Chris helped write. > > Allow me to quote from MS-CIFS: > > MaxMpxCount (2 bytes): The maximum number of outstanding SMB operations > that the server supports. This value includes existing OpLocks, the > NT_TRANSACT_NOTIFY_CHANGE subcommand, and any other commands that are > pending on the server. > > There's nothing in there that says anything about certain commands > being excepted from that value. The only way to know this for sure is to put in a request to Microsoft doc-help to ask if SMBecho and blocking SMB locks are exempted from the maxmpx count. Jeremy. -- 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
