[Ocfs2-devel] [PATCH 2/2] ocfs2/dlm: Migrate lockres with no locks if it has a reference

Wengang Wang wen.gang.wang at oracle.com
Tue Nov 23 18:17:27 PST 2010


On 10-11-23 16:40, Sunil Mushran wrote:
> On 11/22/2010 12:17 AM, Wengang Wang wrote:
> >I think we can consider MIGRATING as BUSY(DLM_FORWARD) and the creating thread
> >should retry in case the owner has changed after the migration.
> >
> >code it as something like this:
> >
> >static enum dlm_status dlmlock_master(struct dlm_ctxt *dlm, ...
> >{
> >	...
> >	spin_lock(&res->spinlock);
> >	__dlm_wait_on_lockres(res);
> >	if (unlikely(res->owner != dlm->node_num)) {
> >		spin_unlock(&res->spinlock);
> >		return DLM_FORWARD;
> >	}
> >	...
> >}
> >
> >And if it's from a handler path, just return the DLM_FORWARD; Otherwise
> >retry in dlmlock(), (goto retry_lock).
> >
> >The above should be taken care in my patch "check lockres owner in handler path",
> >not for only handler path but also the "local create" path. But seems I
> >missed it.
> 
> Is this related to the bug we were discussing yesterday? If so, then
> the flush_workqueue() is a better solution, IMO.
Sunil,
No, it's separated problem. It hopes to solve some invalid lock name
problem.

It will take care the situation that the owner changed after
__dlm_wait_on_lockres(). Say owner changed from local node to other node
after migration. Or it changed from other node to local node in the
situation of migration + crash.

If we don't take it in to consideration, we may then continue to do
"master work" on a non master node or to do "non-master work" on a
master node.

On a non-master node, it can avoid sending request to wrong master in
case local node takes the ownership after __dlm_wait_on_lockres().

regards,
wengang.



More information about the Ocfs2-devel mailing list