> Oplocks do not break things. Oplocks will guarantee consistency. They
> are granted when only one client OS has a file open letting that client
> OS perform locking and caching operations internally without consulting
> the server each time. If another client wants to open the file, then
> that second open request is held up by the server, the first client
> contacted and asked to flush any outstanding data, acquire locks, and
> drop the oplock. Once that has happened then the second client gets the
> answer to its open request.
How is the first client 'contacted' and asked to respond?
I can't see how this is anything but useless. I can't imagine very many
programs honor this kind of request since I've never even heard of this
before last week. If the first client doesn't respond to the request
it would have to degenerate to a standard lock. Is this an OS hack
designed in for a specific microsoft application?
The client is the SMB/CIFS file system driver, not the application. It
is all transparent to the programmer, and that is the problem, because
if the operating system doesn't handle this well (in other words, is
bugged) the programmer has no idea it's corrupting it's own file.
One advantage of using a samba server for this is that you can
configure each share and even fake oplocks (meaning just ignoring) on
read-only media (like a shared CD/DVD drive), meaning substantial
performance improvements (the data can be all cached on the user OS).
> There are other forms of oplocks that allow for opening and closing the
> file multiple times without consulting the server as well as some forms
> of limiting sharing (dropped when clients start using byte range locking).
>
> There have been some problems with Windows when smb signing is in use as
> the design of smb signing assumes request response pairs whereas oplock
> break notifications are asynchronous. Other than degenerate cases,
> current Windows versions have been patched.
Degenerate cases? This sounds like something only Microsoft could dream
up, so I guess degenerate applies... ;)
The whole idea is actually quite clever, but the problem is that it
was idealised before people understood everything about networked file
systems (the security aspect was completely overlooked at the
beginning). The current versions are quite good, but as they have to
be compatible with older clients (Win9X), a lot of hacks need to be
done (not forgetting it was done in a time Microsoft didn't believe in
the future of TCP/IP).
For better or worse, is still the major network file system for small
networks (and I don't see any future change on this).
Regards,
~Nuno Lucas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
