--0016363b8f00077ed704849d2025
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 19, 2010 at 10:55 AM, Andrew Deason <adeason@sinenomine.net> wrote:
> On Mon, 19 Apr 2010 09:41:06 -0600
> Ken Dreyer <ktdreyer@ktdreyer.com> wrote:
>> flock - Whole-file locking. This completely hung on Solaris when
>> opening sqlite files on read-only mounts. Even if the SQLite
>> operations were read-only (SELECT, etc), PHP hung.
>> dot-lock - did not work, as SQLite wanted to write dot-files to our
>> read-only mounts.
>> Er, by 'read-only mounts' you do mean directories where you only have
> read permissions, right? Not mounting RO volumes?
I meant the latter. We need SQLite to be able to read from RO volumes,
and read/write to RW volumes. With
SQLITE_FIXED_LOCKING_STYLE=flockLockingStyle I can read and write to
RW volumes, but any operation on an SQLite file in a RO volume hangs.
At first I wondered if this was a problem with *all* flock() calls on
RO volumes, but I wrote two test programs (C and PHP, attached) to do
a simple shared lock with flock(), and these work on RO and RW
volumes. This makes me think that the problem may be with SQLite's
code, or PHP's use of SQLite. With these test results, I was hesitant
to open a bug with OpenAFS yet.
On Mon, Apr 19, 2010 at 10:01 AM, Derrick Brashear <shadow@gmail.com> wrote:
> can i suggest trying it on a directory where you have rlk and not merely rl?
The ACLs were one of the first things I looked at, but "k" seemed to
have no effect. I will try to build SQLite aside from PHP to see if I
can narrow the problem further. I'll try to provide backtraces /
cmdebug too, when I can pull them together.
- Ken
--0016363b8f00077ed704849d2025
Content-Type: text/x-csrc; charset=US-ASCII; name="lock.c"
Content-Disposition: attachment; filename="lock.c"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g87ptfj90
LyoKICogYnVpbHQgb24gU29sYXJpcyB3aXRoCiAqIGdjYyAtTC91c3IvdWNibGliLyAtUi91c3Iv
dWNibGliLyAtZyBsb2NrLmMgLW8gbG9jayAtbHVjYiAKICovCiNpbmNsdWRlIDxzdGRpby5oPgoj
aW5jbHVkZSA8L3Vzci91Y2JpbmNsdWRlL3N5cy9maWxlLmg+CgppbnQgbWFpbigpCnsKICAgIGlu
dCBmOyAgLyogRmlsZSAqLwogICAgZnByaW50ZihzdGRlcnIsICJPcGVuaW5nIGZpbGUuLi4iKTsK
ICAgIC8qIEEgZmlsZSBpbiBhbiBBRlMgdm9sdW1lLCBSVyBvciBSTyAqLwogICAgaWYoLTEgPT0g
KGYgPSBvcGVuKCJsb2NrLnR4dCIsIE9fUkRPTkxZICkpKQogICAgeyAgIAogICAgICAgIGZwcmlu
dGYoc3RkZXJyLCAiRmFpbGVkLlxuIik7CiAgICAgICAgcmV0dXJuKDEpOwogICAgfQogICAgZnBy
aW50ZihzdGRlcnIsICJEb25lLlxuIik7CgogICAgZnByaW50ZihzdGRlcnIsICJTZXR0aW5nIGEg
c2hhcmVkIGxvY2sgb24gdGhlIGZpbGUuLi4iKTsKICAgIGlmKC0xID09IGZsb2NrKGYsIExPQ0tf
U0gpKQogICAgeyAgIAogICAgICAgIGZwcmludGYoc3RkZXJyLCAiRmFpbGVkLlxuIik7CiAgICAg
ICAgcmV0dXJuKDEpOwogICAgfQogICAgZnByaW50ZihzdGRlcnIsICJEb25lLlxuIik7CiAgICBy
ZXR1cm4gMDsKfQo=
--0016363b8f00077ed704849d2025
Content-Type: application/octet-stream; name="lock.php"
Content-Disposition: attachment; filename="lock.php"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g87ptg9p1
PD9waHAKCi8vIEEgZmlsZSBpbiBhbiBBRlMgdm9sdW1lLCBSVyBvciBSTwokZnAgPSBmb3Blbign
bG9jay50eHQnLCAncicpOwoKaWYgKGZsb2NrKCRmcCwgTE9DS19TSCkpIHsgLy8gZG8gYSBzaGFy
ZWQgbG9jawogICAgZWNobyAiR290IHRoZSBsb2NrLlxuIjsKICAgIGZsb2NrKCRmcCwgTE9DS19V
Tik7IC8vIHJlbGVhc2UgdGhlIGxvY2sKfSBlbHNlIHsKICAgIGVjaG8gIkNvdWxkbid0IGdldCB0
aGUgbG9jayFcbiI7Cn0KCmZjbG9zZSgkZnApOwoKLyogRU9GIGxvY2sucGhwICovCg==
--0016363b8f00077ed704849d2025--