On Fri, 20 Aug 2004, Matt Sergeant wrote:

Right, but regardless of what locking you ADD to the system, sqlite is still
going to do the lockd NFS locking itself. At least until you provide patches
to make NFS locking safe :-)

my current scheme, which may not be entirly fool proof, i first obtain a read or write lockfile. because i have already obtained the 'correct' type of lock the fcntl call in sqlite should ALWAYS return success - eg i should never see 'database locked' or, in my case using ruby, have a SQLite::Database::LockedError thrown. iff i do see this error/exception then i know that nfs locking has broken (stale lock) and upgrade my lock to write (if i have a read) and then do

  mv db db.tmp
  mv db.tmp db

this clears up any stale locks.  i assume here that in the case of broken
locking - fcntl, when used with non-blocking flags, will still return an error
and not block.  if fcntl does block with flags set to non-blocking then i'll
simply shoot myself and anyone who says the word 'posix'.  ;-)

make sense?

NFS locks can get stale if you have network problems. The server loses the
client, the lock remains on the server, nobody can lock the file. Everyone
using NFS eventually runs into this, but good network setup and good kernel choices can often mitigate it.

ours is pretty good but i have that exact situation right now. it's happened in a peice of code i've designed to try and break nfs locking. it forks children which get a lock and don't release it, but simply '_exit'. also, the parent randomly sends SIGKILL to the children after forking them. this loops as fast as possible on many clients locking the same file. it takes a few days, but i can create the situation you describe. i've got a stale lock now that i can see in /proc/locks - and can see the pid of it, but cannot find this pid on any system. do you know if there is a way to find out which host the nfs sever thinks the lock is on? i've got a thread going on the nfs list regarding this but have gotten no help on the specific issue.

thanks again for your helpful comments.

kinds regards.


-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. | --Dogen
===============================================================================

Reply via email to