[cifs-protocol] SMB1 -- proper client behavior when it does not hold an oplock

Jeff Layton jlayton at samba.org
Fri Apr 27 12:27:10 MDT 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dochelp!

I'm hoping you can help clarify some points about proper SMB1 (and
maybe SMB2?) client behavior when it does not hold an oplock (at least
one that allows write caching).

My understanding has always been that when a client does not have an
oplock that allows write caching, then it should not cache any writes
- -- full stop. If an application does a write then the kernel should not
return until it has been sent to the server and the reply has come
back. That behavior is at least suggested in MS-CIFS, though it does
not come out and state that explicitly.

OTOH, Steve French suggested that that's not required by the protocol
and that clients are allowed to buffer up writes "briefly" in order to
allow the redirector to batch up small writes into a single request as
long as it flushes them out in a timely fashion. That seems a little
crazy to me, but I guess it's not the craziest thing in SMB1 if so...

So I guess my questions are:

1) What does the protocol actually mandate? Are you allowed to briefly
buffer up writes before returning to an application when the client
holds no oplock?

2) What does Windows actually do in this regard? If you are not allowed
to do that by the protocol, then does it follow this strictly or does it
do as Steve suggests and batch up small writes until it can fill a
write request?

Thanks for any info you can provide!
- -- 
Jeff Layton <jlayton at samba.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBAgAGBQJPmuUCAAoJEAAOaEEZVoIVNAYP/AguYKBwaYTmTLMqKaMxHyEv
gHiOF0dXIlvu51iHx4fvhY0cBptZwNoa2nEDWdhhEbUxnbZ8QxKw8E4BW87BbKx6
tSKAW6FD5A5m9TCA4qazYjksJYqiXtYdvtPuMSShiZErrQiir/USMD8DK5b/FYer
sEU91HcOZzwaIWHb8sewxohsKvXcMaq8/Ufs7i1bmEQrx+EaA6yeF6W5aXxXtHag
0E9EcAowAd3MJZr6RglvvGJ+kgPAA7g4nhY13eA9iBSGQRPaFC/+PR1KsBwynRzV
UAylnDJrbDdWsM1lpyAqRG/X7S2gYYLiOqhBYoBaaZg5yKdzcBGi829d5HBWUeQy
r2CZ1IbN3rNM5UW4gW+TS1bhd+E1XiNyDDUPLad1DeIP8DhAes+aTjKHVWNev7Cw
fCFt3GFl8HC/rjVQzkD4QCN/OyXyDlv745+Ud/FHgu6osJAo4F8ANU3MH+rXgbH1
mWn2N8lD/ZTJuDMlOiMmz0ABXKd2qcFn6uIE7+o8wIj59sXz+ZN23JckKk2jbNqJ
puJ3mEhacQNXUs4P3jLJBqwzx1fqg9Ego+Pnh9VKm9v2lOshscwscBBroXttNE4l
4F9PZdm0KCDWa0yNJKSZxdM8WU0RBp2+9M9BVRJawnlskMh/f8cWSHDlMnx5AAon
n1oPgAuAUFTCjR3tq6QO
=hKCL
-----END PGP SIGNATURE-----


More information about the cifs-protocol mailing list