[OpenAFS] safe+portable way to determine if byte-range-locking is dangerous?
Adam Megacz
megacz@cs.berkeley.edu
Fri, 15 Dec 2006 10:04:02 -0800
I'm using sqlite right now -- it's a very tiny embedded "databaselet".
It's much more like libdb on steroids than, say, Oracle. I would like
to store the database file in /afs, provided that 99% of the time only
a single process on a single client will be accessing it.
By default, sqlite uses byte-range locking to support fairly
inefficient sharing of a single database file amongst multiple
processes. I plan on contributing code to let it fall back to an
(even more inefficient) strategy which relies only on whole-file
locking.
However, I am faced with a problem: how should the modified sqlite
know when to fall back? It can't really link against any afs-specific
libraries. Essentially what I want is a way of asking the OS "will a
byte-range-lock request lie to me?" and be very, very, very, very sure
that I'm being given the correct answer.
Unfortunately it appears that I'm going to have to change the file
format in some incompatible way to eliminate the possibility of
somebody using a non-afs-aware version of sqlite on a database file
which resides in /afs. This might end up being a deal-killer in terms
of getting the changes accepted upstream, since sqlite prides itself
on a very stable file format. Argh.
I guess my real problem is the installed base of sqlite clients that
aren't aware that byte-range locking is sometimes unsafe when afs is
involved.
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380