How *exactly* does the file caching mechanism work?

David Collier-Brown davecb at Canada.Sun.COM
Thu May 28 14:08:09 GMT 1998

On Thu, 28 May 1998, Jiva DeVoe wrote:
> The question is, if you have two workstations that open the same file on the
> server, A and B, if Workstation A were to lock a record, and write data to
> that record, then unlock the record, then if workstation B were to read from
> that record, would there be any sort of difference between the data?  [snip]
> The main reason the question came up is because we have experienced data
> corruption in situations where the 95 client machines didn't have caching
> disabled.  As a result, we have required that everyone disable caching on
> the server as well, but I don't think this is really needed.

Luke Kenneth Casson Leighton wrote:
> so.  question.  by "workstation" in paragraph 4, do you mean the
> "workstation smb client-side cacheing, which means opportunistic
> locking" or do you mean "the foxpro application _running_ on the
> workstation which _may_ apply its own read/write cacheing"?
> [yes this is an issue: take SourceSafe, for example.  it can apply its own
> locking mechanism or it can use the native file system one, and this is
> configureable in SourceSafe itself].

	Over and above the client-side bugs Luke mentions,
	this is an area fraught with opportunities to fail.

	In the specific case of record-locking applications,
	the client should do as little as possible, and provide
	as much information to the backend as possible. The
	rcord-locking case is classically the small-data-volume
	TP case, and databases do them Really Quite Well.

	In large-data applications, the clients should do
	as much locally as possible, and hold large-grained
	locks on the back end.  This is exactly what Samba
	and MS do with oplocks on entire files. This is
	**spiffy** for whole-file editing, another common
	(non-tp) thing.

	Front and back each depend on each other to Do The Right
	Thing in both these scenarios, so client misconfiguration
	and/or Foxpro misconfiguration or even mismatch can 
	result in corruption.

	Just for information, client-side caching of short-lived
	or read-only data can have contraintuitive effects on the server.
	If you have largish data (e.g., images) used by many clients
	at once, but which are read-only or read-mostly, simpleminded
	caching without oplocks will actually reduce performance.
	It turns out the server doesn't see all the references on
	the client to the data, thinks it hasn't been used lately
	and drops the underlying file from the disk cache!
	[Which surprised the bejasus out of me and required my
	Unix developer-colleagues to reinvent oplocks]

>  if this is a problem, you can disable it by specifying "oplocks = no".
	or  maybe just veto oplocks on the file...

> jeremy had problems with oplocks: he found that win95 didn't bother to
> close files, so had to add some code that, oh i don't know, broke the
> oplock on last used files or something.
> if foxpro has several file handles open you may run into this one, i don't
> know.  try "FILES = 90" in config.sys, see what happens.

David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb at,
M2N 1Y3. 416-223-8968 |

More information about the samba-technical mailing list