[OpenAFS] making sqlite safe-but-slow on afs?

Adam Megacz megacz@cs.berkeley.edu
Thu, 20 Jul 2006 18:27:56 -0700

SQLite is a simple, lightweight in-process database.  Sort of like
libdb2 or BerkeleyDB but with a SQL interpreter.

Multiple processes can safely write to the same database, albeit at a
performance penalty since busy-waiting is used.  However, this is
tremendously useful when you have some data set that is continually
accessed by a single reader/writer, but *occasionally* must be updated
by an administrator (without causing corruption).


SQLite maintains a "lock state" for the database.  This "lock state"
is guarded using fcntl()-locks.  A process may only write to the
database when that "lock state" indicates that the writer has
exclusive access to the database.  If readers are waiting, it will
then call fsync() before changing the "lock state" to "shared".

The database-level locking code is pretty simple and makes few
assumptions, mainly because it needs to be portable across various
OSes with different file-locking APIs:


It all boils down to three locks [*], which are currently implemented
as locks on three specific byte ranges in the database file.  I could
easily break this out into whole-file locks on three separate files.

Does this sound workable for a almost-always-only-one-reader/writer
scenario?  It would save a huge amount of complexity elsewhere by not
having to export an "administration API" from the single-reader-writer

  - a

[*] if you give up support for Win95/Win98 you can ditch the 510-byte
    hack and think of it as three byte-range locks, each of them one
    byte in size.