By erickustarz on Jan 18, 2005
Here's an interesting entry on a faq for sqlite:
The locking mechanism used to control simultaneous access might not work correctly if the database file is kept on an NFS filesystem. This is because file locking is broken on some NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.
The protocol behind locking (NLM) for NFSv2/v3 is not broken\*, but rather some of the implementations were broken - especially early on (people spent time on making the NFS protocol work, but NLM was more complex/an after thought). What is interesting is that we find there really is no difference between perception and reality. People perceive locking over NFS to be broken, so (as demonstrated above) they will not use it. Running a Solaris client against a Solaris server will find that NFSv3 + NLM works great, and is not broken, but it doesn't matter - it is perceived to be broken.
Thankfully, NFSv4 fixed this by integrating locking into the one and only protocol. Now, locking has to work or you don't have a NFSv4 implementation. Don't do locking and you have NFSvhalf-ass-effort.
When people refer to NFSv4 as a stateful protocol, this is the main reason. State has to be kept around to ensure proper locking. NLM had to keep track of state, so does NFSv4.
\*Ok, there are a couple very edge cases in NLM that got sorted out in NFSv4. The easiest example is recovery of a client crash. Upon coming back up, the client's status monitor (statd) will contact the server's statd indicating that the client no longer needs any of its locks. So what happens if the client never comes back up, and another client needs to lock the same file? You need administrative intervention at this point. Since NFSv4's state is leased based, no intervention is necessary -- if the client doesn't reclaim its state within the alloted time, the locks are lost.