posix locking and the brlock database

[Jeremy Allison]

On Sat, May 19, 2007 at 07:43:53PM +1000, tridge at samba.org wrote:
> 
> While the file is locked, a windows client tries to get the lock. It
> will check the posix lock in brlock.c, and see that it can't get the
> lock, so it puts in a pending lock entry in the brlock.tdb record for
> that file.
> 
> Then the NFS client or local unix application releases the byte range
> lock. What triggers the retry of the pending lock? We don't get any
> notification from the kernel, and we don't retry internally.

Ah, phew. You had me worried there :-). Yes we do retry internally,
just not as often as we used to :-).

Look in smbd/process.c :

When calculating the select timeout we call blocking_locks_timeout_ms()
which calculates the timeout to the next blocking lock expiry, or
returns a default timeout if they're all infinite timeout.

The timeout processing code in smbd then calls :
process_blocking_lock_queue() which will retry for any pending
POSIX locks. So we do retry, it's just that we might
have to wait 30 seconds or so.

The old code used to return a timeout of 10s from the old
equivalent of blocking_locks_timeout_ms() if there were any
pending locks on the queue. These days we get messages for
such locks if they're blocked on a Windows lock so what we
need to do is mark any locks blocked on a POSIX lock rather
than a Windows lock and return a shorter (10s) timeout if this
is the case. I'll fix this.

This will be much simpler when everything is eventually
event driven in Samba3. Getting there slowly :-) :-).

Jeremy.