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

[Adam Megacz]

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).

  http://www.sqlite.org/lockingv3.html

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:

  http://www.srcdoc.com/sqlite_3.2.2/os__unix_8c-source.html#l00911

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
process.

  - 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.