When purge a lockres, we unhash the lockres ignore the result of deref request
and ignore the lockres state.
There is a problem that rarely happen. It can happen when recovery take places.
Say node A is the master of the lockres with node B wants to deref and there is
a node C. If things happen in
s/ignore/ignoring/g for the following 2 lines.
When purge a lockres, we unhash the lockres ignore the result of deref request
and ignore the lockres state.
regards,
wengang.
There is a problem that rarely happen. It can happen when recovery take
places.
Say node A is the master of the
thanks for doing this patch. I have a little comment, wondering if there
could be a window where node B sent the lock info to node C as part of
recovery and removed flag DLM_LOCK_RES_RECOVERING while dlm_thread was
still purging it. In that case dlm_thread will still continue to remove
it from
On 10-05-24 12:48, Srinivas Eeda wrote:
thanks for doing this patch. I have a little comment, wondering if
there could be a window where node B sent the lock info to node C as
part of recovery and removed flag DLM_LOCK_RES_RECOVERING while
dlm_thread was still purging it. In that case
delay deref message if DLM_LOCK_RES_RECOVERING is set (which means
recovery got to the lockres before dlm_thread could), move the
lockres to the end of the purgelist and retry later.
If you meant checking before sending DEREF, it could cause a high cpu
useage when there are only the ones in
On 5/24/2010 7:50 PM, Wengang Wang wrote:
delay deref message if DLM_LOCK_RES_RECOVERING is set (which means
recovery got to the lockres before dlm_thread could), move the
lockres to the end of the purgelist and retry later.
If you meant checking before sending DEREF, it could cause a
