[OpenAFS] avoiding data corruption due to byte-range locks

[Adam Megacz]

So, the SQLite changes work:

  http://permalink.gmane.org/gmane.comp.db.sqlite.general/24711

It's kinda neat; you can insert rows into the database on one AFS
client and they show up on another.  The AFS locks+callbacks handle
all the communication in the background.

However, I'm really not happy with the facilities for figuring out if
I need to disable byte-range locks and fall back to the less-efficient
whole-file locking scheme (it turns out sqlite already has code to do
this if told to).

Since OpenAFS 1.5 will apparently have support for byte-range locks,
it seems that at this point no new OpenAFS clients which lie about
byte-range locks will be released (aside from bugfixes, of course).
So, is there some behavior I can test for empirically that will tell
me if the file or directory I'm looking at lies to me about byte-range
locks, such that the behavior is exhibited on all currently-deployed
OpenAFS clients?

I almost had this with the fork()-and-fcntl() patch except for the
fact that the Linux client is too smart and will fake byte-range locks
between processes on the same client.

I have a strong preference for some sort of empirical test like this,
since it doesn't involve linking against any AFS libraries or
including AFS headers, and it feels safer to me than trusting some
sort of strcmp(fstype,"afs").  A false negative here means
catastrophic data corruption.

Thanks,

  - a

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