Batch OpLocks: Are they used much these days ...
David Collier-Brown
davecb at canada.sun.com
Thu Jan 10 04:49:05 GMT 2002
Urban Widmark wrote:
> Batch oplocks allow a lot more caching on the client side. smbfs can read
> pages into memory and does not have to invalidate them even when the file
> is closed, because the batch oplock allows the close to be cached. If the
> file is opened again the pages remain valid.
>
> The smbfs code doesn't actually do that, but it could.
> Why would anyone want just an exclusive oplock?
Arguably for sharing: if the file needs
to be single-writer multiple-reader an
exclusive write lock is appropriate.
If the file is read-only, caching a close
is harmless if and only if doing so does
not leave the file locked against writers!
It's not actually that clean: batch oplocks
exist because early batch processors would
open a file, read one line, close, execute
the line, reopen, seek to the next time and
repeat. The discussion of caching content
from a server on the client then motivated
oplocks, and sure enough, support for the
close-and-reread semantics of the old batch
processor.
But without, it seems, considering the
correctness of holding an implicit
write lock on a file that is treated as
read-only(!)
--dave
--
David Collier-Brown, | Always do right. This will gratify
Americas Customer Engineering, | some people and astonish the rest.
SunPS Integration Services. | -- Mark Twain
(905) 415-2849 | davecb at canada.sun.com
More information about the samba-technical
mailing list