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

[Jeff Layton]

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

On Mon, 21 May 2012 21:13:21 +0000
Obaid Farooqi <obaidf at microsoft.com> wrote:

> Hi Jeff:
> Please let me know if my response answered your question.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com
> 
> 
> -----Original Message-----
> From: Obaid Farooqi 
> Sent: Tuesday, May 15, 2012 10:44 AM
> To: 'Jeff Layton'
> Cc: 'smfrench at gmail.com'; 'crh at samba.org'; 'pfif at tridgell.net'; 'cifs-protocol at samba.org'; MSSolve Case Email
> Subject: RE:[REG:112042860618701] SMB1 -- proper client behavior when it does not hold an oplock
> 
> Hi Jeff:
> The SMB protocols do not have any specific requirement as to how much or how little caching is allowed on the client side. An implementation could very well "choose to batch writes for a short period of time" even in the absence of an oplock/lease.  However, then there are no data consistency guarantees between multiple readers and writers.  Oplocks/leases provide a mechanism for implementers to guarantee better data consistency.
> 
> Windows in general does not do caching in the absence of oplock/lease. The specific conditions in which caching without oplock/lease may happen is implementation detail, not protocol.
> 
> Please let me know if it answers your question.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com
> 
> -----Original Message-----
> From: Obaid Farooqi 
> Sent: Monday, April 30, 2012 10:14 AM
> To: 'Jeff Layton'
> Cc: smfrench at gmail.com; crh at samba.org; pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE:[REG:112042860618701] SMB1 -- proper client behavior when it does not hold an oplock
> 
> Hi Jeff:
> I'll help you with this issue and will be in touch as soon as I have an answer.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com
> 
> 
> -----Original Message-----
> From: Jeff Layton [mailto:jlayton at poochiereds.net] On Behalf Of Jeff Layton
> Sent: Friday, April 27, 2012 1:34 PM
> To: pfif at tridgell.net; cifs-protocol at samba.org; Interoperability Documentation Help
> Cc: smfrench at gmail.com; crh at samba.org
> 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!


Sorry, I thought I had replied. Thanks for the answer, it was very helpful!

- -- 
Jeff Layton <jlayton at samba.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBAgAGBQJPu8mBAAoJEAAOaEEZVoIVZH0QAIO+LAu6zr2W1W+FXXD2cmgj
pPZPd0dMCX44rmk2UciqwAOJszdmq3VeLKrP3HtZKjxMu7xo6buYgYfNpD1dNgy3
ie9XK0Z8xOCkR1EvXNlVBcWaTy/hso2J4agpt2aKX+iY4Z8IA6D+3YhMhxAXBUsR
hU+mdfOvFZ3HQEGI7nFJCT45HXR6TIx0HntO/qslbf0NFYMJrPkp7iP33BCPKTOO
yr8UKQXRINGZk1wa+dlMjsihoNhDsR5SXLa73oIUbFs3vT2FE8kIBq56pJ0HwMTa
JW9PXkaztBXFLVnAMumscn6P5wxOVtZdljwGWEYleEmjNSW0RgJ4vaQXkYP5cSkN
y2mspEuQCadyTxGxCg8KfXWH9IOTUM31GJtVKUh4tzwpy3qTbG4wdgow7Iktzuzc
nTKFEinYxGYIo8rfJSItuBnzNZyld1XW7JrtIhXPEb1QLqvt0fEgSk52BhuRiWnB
qrV6qOb8Gogh6roaVGMCaltobzD4Y5xzosEwM9KGi5Rxc68y9xA4Yr/ujRvrVLi1
I0JCm82WwKCarpTQnoIUryWEjvsuS3NhCRSuXz+ICY4Yso9uuOOexHoC7cbTrTOm
SaP4lUBwE/8zAdgYA/qlnsastZ+LGX+DcyBzgmIdmYzlJJr8b5WcxpVrNp+Fq0p7
npmQWOG8Q0ARdF+Uu5Yq
=cMIz
-----END PGP SIGNATURE-----