On 19 Oct 2011, at 11:20pm, Nico Williams wrote: > On Wed, Oct 19, 2011 at 4:16 PM, Jay A. Kreibich <j...@kreibi.ch> wrote: >> Just because the standards include such features, you seem to be >> under the impression that every client and every server running on >> top of any filesystem actually implement said features correctly, >> and that every combination of client and server interacts and >> operates correctly. > > I assume that? I'm aware that the Linux NFS client did not support > distributed byte range locking prior to kernerl 2.6.12. That doesn't > mean that SQLite3 couldn't have an option to do locking in a way that > would work with NFS -- it just means that it'd be unsafe to use > SQLite3 on NFS on older Linux distros with any concurrency, that the > application would need additional locking (like, e.g., Firefox does or > used to).
I started off with that impression but it turns out that pretty much all implementations of everything have bugs in the locking code. Forget 'older Linux distros', we're talking distros yet to be issued. If you actually demand proper implementation of range-locking you're out of luck. Fixing the bugs slows them down to the point everyone would complain about how stuff has slowed down. I spent some time on this before concluding that it would be simpler to write a server/client overlay for SQLite, and that would yield faster results than getting all the locking code working properly for any of the big well-known network file systems. People who know what I work with know I'm a huge Apple fan and when I give up on getting AFS working right you know there's something seriously wrong with it. A server/client architecture has the additional advantage of platform interoperability, and that you can use PRAGMAs to turn off some of the features of SQLite that slow things down. You just turn file sharing off and assume that your server has sole access to the file. >> As for modifying SQLite, the locking mechanism is actually somewhat >> modular, and I believe SQLite already includes the ability to some >> types of range locks. That still doesn't do you any good if the >> filesystem doesn't answer the APIs correctly. > > True, but one would have to make sure that older releases of SQLite3 > don't open a DB that uses a lock protocol that they don't support. > That can be done by, e.g., having a different magic, but I think we'd > all want the new thing to NOT be the default. Putting SQLite aside I wrote a program which generated a list of commands to test the network APIs: random ranges to lock, things to write to the file, ranges to unlock, things to read from the file. Couldn't get it to work on modern implementations of anything: SMB, NFS, AFP. Always found situations where range locks were ignored by another client, or unlocks apparently got executed without having any effect. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
