-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 1 Mar 2012 10:48:23 -0800
Jeremy Allison <jra@xxxxxxxxx> wrote:
> 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.
>
That will probably tell us what Windows does, but the problems are not
necessarily with Windows servers. There are a lot of crappy CIFS
servers in the field and Microsoft can't tell us how they behave in
this regard.
Still, it won't hurt to ask, so I'll do so...I just don't think their
answer will have much bearing on what we'll eventually have to
implement.
- --
Jeff Layton <jlayton@xxxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJPT8owAAoJEAAOaEEZVoIVkVAQAK7Z9a+krmXnUQmbfjYr+jEd
bvpXp2FWpiJxzhnv4EQPoMHlWUjYc2mCLeOvo/42pcYzDzx0Gko4F9hfJJTB7Rj6
RqueGzJpvjpuw+HNo3t0YUXU+/OU2E+OBCEnuQ5a7K2sJGI4BUmXLfXKeCaWL8Bz
5H/CdbUkzFM6TH9QTe7vbwkHRgTBqMPd7Ugy1crWWO0thJpkRF9MkJCCdaXIxkgP
LiN10E5D5wkfTdb0SWAhYvc8FvEkS8wKEQcM+BN45PqaWiW2gMZpS4cgQdcWzH1I
Dlz2zJlMZlV5f71DQVHCDvlY44TfN/LjlnA1+wW6h/QhJomJQhZKzTk2aqThiF4h
iNCOPvlDuBab0ZAynGj7VA4KZ0DNY/CVrqH20OHW9ROkLCjcqCHgvx5eEGXPkWcm
HhY88eWpmrj7nxZ+zqipKwlJas8Zu7NYixGWEPQ3j+dxebhxLKfqBDQBgpXpoZFH
WhEp5L33RF4NUkKy0ToihXjxp8HLEFhfOAgTzbKJS4GtPDfyckXqw3yL967gZEV3
LJEBjI5+kjUOEIHt+/uhSQDVM/uT+sFMQpBbtGguK0k4WIIbFgT3cvG/SnCUIdXB
O9jEZTZ7DtZY6rG35Kq05usclWFz9Fi2u/FVTqZxJcM8ufuY5c5vApL9SPgzN7zr
qGPm7BM6MP2x+kVL3fHs
=clwm
-----END PGP SIGNATURE-----
ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±ýÈ?³ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
