diff options
author | Zack Kirsch <zack.kirsch@isilon.com> | 2009-02-09 21:54:51 -0800 |
---|---|---|
committer | Jeremy Allison <jra@samba.org> | 2009-02-13 10:08:55 -0800 |
commit | a3531314dd6c7da05e4b35cc84a8c3a0addaa0a4 (patch) | |
tree | 4f392fe23ff2be91a6de2f9a51587923725eb870 /source3/include | |
parent | 813273c87e4f48d7d8415c8ee9a1a553ed369429 (diff) | |
download | samba-a3531314dd6c7da05e4b35cc84a8c3a0addaa0a4.tar.gz samba-a3531314dd6c7da05e4b35cc84a8c3a0addaa0a4.tar.bz2 samba-a3531314dd6c7da05e4b35cc84a8c3a0addaa0a4.zip |
OneFS implementation of BRL VFS ops:
* Much of the beginning should look familiar, as I re-used the OneFS oplock
callback record concept. This was necessary to keep our own state around - it
really only consists of a lock state, per asynchronous lock that is currently
unsatisfied. The onefs_cbrl_callback_records map to BLRs by the id.
* There are 4 states an async lock can be in. NONE means there is no async
currently out for the lock, as opposed to ASYNC. DONE means we've locked
*every* lock (keep in mind a request can ask for multiple locks at a time.)
ERROR is an error.
* onefs_cbrl_async_success: The lock_num is incremented, and the state changed,
so that when process_blocking_lock_queue is run, we will try the *next* lock,
rather than the same one again.
* onefs_brl_lock_windows() has some complicated logic:
* We do a no-op if we're passed a BLR and the matching state is ASYNC --
this means Samba is trying to get the same lock twice, and we just need
to wait longer, so we return an error.
* PENDING lock calls happen when the lock is being queued on the BLQ -- we
do async in this case.
* We also do async in the case that we're passed a BLR, but the lock is not
pending. This is an async lock being probed by process_blocking_lock_queue.
* We do a sync lock for any normal first request of a lock.
* Failure is returned, but it doesn't go to the client unless the lock has
actually timed out.
Diffstat (limited to 'source3/include')
0 files changed, 0 insertions, 0 deletions