-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/10/11 13:24, Nico Williams wrote: > That explains why concurrent access over NFS or CIFS is dangerous. It > doesn't explain that it's not possible to use SQLite3 over NFS or > CIFS.
The simple answer is that they don't provide *exactly* the same behaviour and semantics when using the same system calls accessing files remotely versus locally. This is typically due to bugs in their implementations in code paths that aren't often used. > Also, regarding NFS, it would be safe to use if SQLite3 were to use > whole-file byte range locks. NFS has other issues. For example NFS lock daemons had a tendency to crash when dealing with offsets in the 2GB range. Samba has code to translate locks from the crash sensitive range to elsewhere. > Of course, safely making changes to how SQLite3 locks files may be > difficult now... It is impossible since a different version of SQLite could also be accessing the file on the client or the server. > CIFS does support byte range locking, and I suspect that the same rule > I mentioned above regarding NFS applies. CIFS locking is worlds apart from NFS locking with many differences. One of the hardest parts of writing a CIFS server for Unix is mapping into the limited locking on Unix (which is substantially similar to NFS locking). > Plus, as a last resort there's CIFS open deny modes that SQLite3 could > use to prevent concurrency. The UNIX VFS has something similar already implemented and could be ported to the Windows VFS. See section 2: http://www.sqlite.org/vfs.html > In response to other comments regarding other filesystems, I'll point > out that on Lustre, because Lustre is fully POSIX-compliant regarding > write visibility, SQLite3 should work fine as-is. The problem isn't necessarily that the filesystems work as documented, but rather that the sequence of operations that SQLite does is somewhat unusual compared to normal programs and hence hits various obscure bugs as has been repeatedly found by user experience. There is both client and server side code where those bugs could lie. It is virtually impossible to prove the absence of bugs, so if you want to risk your data then go ahead, but expect an "I told you so" if you end up with corruption. And since you are already using networking there are numerous database products that already work that way and won't have the issues. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6fS+gACgkQmOOfHg372QQENACeJrNUpnFgSIvLlgNrRICOF6Oc ajgAnRoBSwRk0uKQ/0D3i+zAmU2sEqnZ =yIct -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
