Batch OpLocks: Are they used much these days ...

[David Collier-Brown]

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