On 4 May 2015, at 1:30am, James K. Lowden <jklowden at schemamania.org> wrote:
> That is the way most remote filesystems are designed and implemented > and documented. Cf. http://www.ietf.org/rfc/rfc1813.txt: > > 4.11 Caching policies > > The NFS version 3 protocol does not define a policy for > caching on the client or server. In particular, there is no > support for strict cache consistency between a client and > server, nor between different clients. See [Kazar] for a > discussion of the issues of cache synchronization and > mechanisms in several distributed file systems. > > If you can find documentation for cache semantics for CIFS, I'd be > interested to see it. In contrast to NFS both SMB and AFP are designed to support networks properly, with caches only on the computer which hosts the file and locking correctly implemented. And SQLite, whether it's depending on the locking built into them or its own mutex, should work correctly. The problem is that the network file system implementations don't perform according to the design. I don't work at this level but as I understand it there are two main reasons: bugs and speed. I'm going to ignore bugs here. The speed problem is that properly supporting locking slows down operations a lot. Instead of one operation you do lock-read-unlock which takes almost three times as long. And that's assuming that the lock succeeds. So a thing you don't do in a client demo is show them the system running single-user, because when they get their own multi-user copy of your system they're going to start screaming about how slow it is. So manufacturers at all the drivers in the chain -- OS, network file system, disk file system -- tend to implement locking badly to make themselves look fast. Failing to properly handle unlikely cases here and there to save the time taken to figure out whether they apply. And SQLite is incredibly intensive on locking and file operations, so it quickly routes out such problems. Simon.
