🚀 go-pugleaf

> From: Jeff Anton, Ingres Group <ucbvax!anton>
>
> A DBMS would be well off with three (3) levels of locks [...]  shared,
> update, and exclusive. [...]  If you think you might have to change some
> data in a file you get an update lock.  [...]  If you do have to change
> the data you raise the lock to exclusive and wait until all the shared
> locks go away.  Know what else goes away?  Deadlock.

	I'm not sure I follow.  I don't see how the update lock is anything
more than a hint that you might want an exclusive lock later.  Like all
hints (vadvise for example), this may improve efficiency, but I don't see
how it really changes anything in the end.  In particular, how does this
eliminate deadlocks (and why doesn't the 2-stage 4.2 flock)?

	Since we're on the subject, there's something I don't understand
about the 4.2 flock(2) call.  As I understand it, having a shared lock
guarantees that the file can't change beneath you.  But when you update
your shared lock to an exclusive one, "this results in the previous lock
being released and the new lock applied (POSSIBLY AFTER OTHER PROCESSES
HAVE GAINED AND RELEASED THE LOCK)" [my emphasis].  This doesn't make
sense; you poke around in the data base to figure out what you want to do
and then, just before you are ready to write your changes, you give
somebody else a chance to write theirs?  Doesn't that mean that you then
have to go back and re-compute your whole update?

	I can see how *not* giving others a shot when you upgrade a lock
might lead to deadlocks (which would answer my previous question nicely,
thank you).  As I read the manual, though, it just doesn't make sense.  Can
somebody tell me what I'm missing (if anything)?

> [talking about reliability and limitations of the file system]
> But for the banks and the purests, we're working on what may be a way
> around the problems.  I'm not sure enough right now to publicize yet.

	If there are problems with the file system, why can't you just open
up a raw disk and implement your own like was done for testing the 4.2 F.S.
under a 4.1 kernel?  I don't see any way to get around the write-behind
strategy in the block I/O system, but at least you can make multi-volume
files if you want.  You could even implement shadow pages and volumes (to
keep "the banks and the purests" happy) in the user-level file system
routines.  Cpu cycles *are* cheaper than HSC-50's, aren't they? :-)
-- 
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016