How *exactly* does the file caching mechanism work?
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
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 hobbes.ss.org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
More information about the samba-technical