[OpenAFS] safe+portable way to determine if byte-range-locking is dangerous?

[Marcus Watts]

Adam Megacz <megacz@cs.berkeley.edu> writes:
> To: openafs-info@openafs.org
> From: Adam Megacz <megacz@cs.berkeley.edu>
> Message-ID:  <x31wn19gtp.fsf@nowhere.com>
> Subject: [OpenAFS] safe+portable way to determine if byte-range-locking is dangerous?
> Date: Fri, 15 Dec 2006 10:04:02 -0800
> 
> 
> I'm using sqlite right now -- it's a very tiny embedded "databaselet".
> It's much more like libdb on steroids than, say, Oracle.  I would like
> to store the database file in /afs, provided that 99% of the time only
> a single process on a single client will be accessing it.
> 
> By default, sqlite uses byte-range locking to support fairly
> inefficient sharing of a single database file amongst multiple
> processes.  I plan on contributing code to let it fall back to an
> (even more inefficient) strategy which relies only on whole-file
> locking.
> 
> However, I am faced with a problem: how should the modified sqlite
> know when to fall back?  It can't really link against any afs-specific
> libraries.  Essentially what I want is a way of asking the OS "will a
> byte-range-lock request lie to me?" and be very, very, very, very sure
> that I'm being given the correct answer.
> 
> Unfortunately it appears that I'm going to have to change the file
> format in some incompatible way to eliminate the possibility of
> somebody using a non-afs-aware version of sqlite on a database file
> which resides in /afs.  This might end up being a deal-killer in terms
> of getting the changes accepted upstream, since sqlite prides itself
> on a very stable file format.  Argh.
> 
> I guess my real problem is the installed base of sqlite clients that
> aren't aware that byte-range locking is sometimes unsafe when afs is
> involved.
...

Does sqlite make any attempt today to see if byte range locking works,
and have logic to fall back to something else if it's not there?

Does sqlite have any afs-aware logic today?

I can't answer for the sqlite end as to what exactly would be acceptable
to those folks, but I suspect they'd be most happy with a very portable
non-specific type of fix - in this context, it should probably be
something that can tailor itself at runtime to what the local filesystem
provides.

I don't think afs has any way today to indicate what sort of locking
behavior it has.  The only way is to try it & see.  I think, though,
that it might be simple enough to add a mechanism that would communicate
in some "non-afs" fashion whether locking works.  A simple fashion might
be some equivalent to "fs setcrypt" that toggled "AFS lies about locking"
behavior.  A slightly more comprehensive solution would be to make this
per-pag so that different users or runtime environments could have different
behavior.  (Making fs setcrypt work this way might be interesting as well.)

There is some effort underway to improve locking behavior in AFS.  Today,
AFS byte ranges can in some cases work on the local workstation, but not
to other workstations.  There's some work underway (mostly planning today)
to make this inter-workstation (server-based) as well.  That means at some
point in the future, you may be looking at an array of possible behavior from AFS:
	global whole-file locking only.
	local byte-ranges, global whole-file locking.
	local & global byte ranges.
		x
	client lies to the application
	client tells the truth to the application
		x
	possible per-cell, per file-server, and/or per-pag differences
	in behavior
					-Marcus