[OpenAFS] Re: Databases & AFS (revisited)

[Adam Megacz]

Davor Ocelic <docelic@mail.inet.hr> writes:
> We are considering the placement of users' MySQL and PgSQL
> database files within their AFS volumes.

I'm working on getting SQLite working in AFS.  As long as there's only
a single client accessing the database, it should perform fairly well.
Note that SQLite is an in-process database, so the client "is" the
server, so this is really more like saying "as long as there is only
one *server* accessing the database," which is more reasonable.

Right now my only remaining concern is finding some way to make
locking safe.  SQLite can be modified to rely only on whole-file
locking (at a greater performance penalty in the multiple-"server"
case), so I need to:

  1. Create a new AFS-aware version of SQLite that tests whether or
     not requests for byte-range locks on a database file will
     "succeed" even when no lock was granted.  This should be done in
     a portable way that does not require linking against anything
     AFS-specific (so that the changes can hopefully be upstreamed
     into SQLite).

  2. When creating or writing to a database file within AFS, alter its
     format in some incompatible way so that non-AFS-aware versions of
     sqlite will not accidentally corrupt it by relying on false
     byte-range locks (I have observed this happen).

I'm having trouble with figuring out a portable/clean way to do #1.

If I can solve this, it would be a pretty powerful combination.  You
could administer the database from any AFS-enabled machine, although
doing so would probably cause the "main" database accessor to slow
down considerably during the period of lock contention.  For
short+rare administrative activities this shouldn't be a problem,
though.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380