[OpenAFS] Re: Databases & AFS (revisited)
Sat, 23 Dec 2006 10:44:35 -0800
Davor Ocelic <firstname.lastname@example.org> 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
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,
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380