[OpenAFS] Shared r/w access to numerous sqlite databases: an
appropriate application for AFS?
Thu, 8 Apr 2010 16:06:18 -0400
On Thu, Apr 8, 2010 at 2:18 PM, Matt W. Benjamin <firstname.lastname@example.org> wrote:
> Simon is correct. =A0A byte-range locking implementation for OpenAFS is b=
eing funded by Your File System, Inc., under its DOE SBIR Phase II grant. =
=A0As stated elsewhere by Jeff, there are (or will be) structures for makin=
g completed available to the community during the course of the work.
> However, my understanding that shared r/w access to sqlite through AFS pr=
obably does work, provided you ensure sqlite uses the correct locking style=
(cf. sqlite's os_unix.c):
> #define SQLITE_WHOLE_FILE_LOCKING =A00x0001 =A0 /* Use whole-file locking=
> This feature is apparently due to Adam Megacz, who posted briefly about i=
t in 2006. =A0See http://marc.info/?l=3Dsqlite-users&m=3D116742195016159&w=
Thanks for the response. It seems like whole-file locking in sqlite
would be a good choice for me in any case, and I can't imagine needing
that kind of writing concurrency.
Doing a little more research, this message describes a few more issues
with sqlite over NFS which I suppose might apply to AFS:
In a situation where the whole-file locking scheme is used, would AFS
be an acceptable choice? Would it be better than NFS?
For instance I envision a handful of clients on different machines
each writing to a single sqlite DB every few seconds; would this
defeat AFS's caching scheme?
Thanks for the thoughtful responses.
> ----- "Simon Wilkinson" <email@example.com> wrote:
>> On 8 Apr 2010, at 12:22, Todd Lewis wrote:
>> Someone (Matt, IIRC) was working on server support for byte range
>> locking, but I don't think we've seen any code yet.
> Matt Benjamin
> The Linux Box
> 206 South Fifth Ave. Suite 150
> Ann Arbor, MI =A048104
> tel. 734-761-4689
> fax. 734-769-8938
> cel. 734-216-5309