Hello Jeff,
Thank you for your inquiry about File sharing protocols. One of
the Open specifications team member will contact you soon.
Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications
-----Original Message-----
From: Jeff Layton [mailto:[email protected]] On Behalf Of Jeff Layton
Sent: Friday, April 27, 2012 2:34 PM
To: [email protected]; [email protected]; Interoperability Documentation
Help
Cc: [email protected]; [email protected]
Subject: SMB1 -- proper client behavior when it does not hold an oplock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry for the duplicate emails, but I sent this to the wrong dochelp address
before. Let me try again...
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 <[email protected]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJPmuasAAoJEAAOaEEZVoIVskQP/0+D09k+8gWthZvBrpbLms1B
q7ZQBcBHNCJZos7ZG+K/9ZHzGVKxtnmW2rDiQ+r5vQ/z9EK4QP3pd6V+LupoFNzI
CCH3fAYgAHgl2W83I/fDNCdrtrvEK0VDYLEFZwltsk5lf5rL9PEfUoFtBq72dz0R
bj6GJM8A3EaiQx431DOszuv+YG6sh50Gw+TkPOYwSpIv8fZbIydXpmlgtBT/kJCm
c/M+lIYrYO5Jisv+GXoYAIOiQAIlIdD5Hw2swMSm7kEQliCxMdY9KjSR/pL6p1HY
7Pbdq1oQg/HhHQzpFmMwUMyJJqBCU5mA2Ze7Q3EUHdE1vxB9vUug0So4IQf/+lEz
1nlOYXuZrepUzjbd/zIrBXfpBuPwR0ja4+XwnaZmXgCAxUijpyomsmCNnsefLcrO
32mHheNaopDijO3S4zYrgmdk4Yrl4KxCNjMQ0q/JRlFsWAbvS98Z1vApzHXzIHND
Zeh8nx698KqVh4GKpKM8KGwT9yCK5ItPqxVlhbdmhna3rjR53kzyjzza+oIOYhBv
i7WMSSpRWQt1h0lVZp9oyBrq2TvNKYXbTu2me9chE44Qe7/D1c/0wpRw0Chzccdy
wnuDTYM5BsBEUZHHEsr42HrdCQ0+UwJo3j8qGdF3HDvq43lx61nmDX5YO4GJVSht
JSJ1jfHYiGPEWnDgUXgj
=P0b9
-----END PGP SIGNATURE-----
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol