On 10-06-27 11:45, Sunil Mushran wrote:
Is it the same patch as targeted for mainline? If so, go ahead.
If not, then please highlight the differences.
almost same as the one for mainline. just
1) make dlm_purge_lockres() static
2) removed the useless declaration of dlm_purge_lockres() from
So when backporting, try to keep the patch as is. The aim is to ensure
the code across trees is as similar as possible. That is not to
suggest that that function should not be static. But the correct
procedure is to change mainline. There is a reason for this madness.
We do this because we
On 10-06-18 09:37, Sunil Mushran wrote:
On 06/17/2010 07:37 PM, Wengang Wang wrote:
On 10-06-17 08:06, Sunil Mushran wrote:
On 06/15/2010 11:06 PM, Wengang Wang wrote:
still the question.
If you have sent DEREF request to the master, and the lockres became in-use
again, then the lockres
On 06/17/2010 07:37 PM, Wengang Wang wrote:
On 10-06-17 08:06, Sunil Mushran wrote:
On 06/15/2010 11:06 PM, Wengang Wang wrote:
still the question.
If you have sent DEREF request to the master, and the lockres became in-use
again, then the lockres remains in the hash table and
On Wed, Jun 16, 2010 at 06:44:43PM -0700, Sunil Mushran wrote:
One way to skip a lockres in the purgelist is to list_del_init() and
list_add_tail(). That simplifies the patch a lot.
I have attached a quick dirty patch. See if that satisfies all the
requirements.
As far as I can
On 6/17/2010 1:32 AM, Joel Becker wrote:
On Wed, Jun 16, 2010 at 06:44:43PM -0700, Sunil Mushran wrote:
One way to skip a lockres in the purgelist is to list_del_init() and
list_add_tail(). That simplifies the patch a lot.
I have attached a quick dirty patch. See if that satisfies all the
On 10-06-17 01:53, Srinivas Eeda wrote:
On 6/15/2010 11:06 PM, Wengang Wang wrote:
still the question.
If you have sent DEREF request to the master, and the lockres became in-use
again, then the lockres remains in the hash table and also in the purge list.
So
Yes, that's a possibility. But
On 06/17/2010 01:35 AM, Srinivas Eeda wrote:
On 6/17/2010 1:32 AM, Joel Becker wrote:
On Wed, Jun 16, 2010 at 06:44:43PM -0700, Sunil Mushran wrote:
One way to skip a lockres in the purgelist is to list_del_init() and
list_add_tail(). That simplifies the patch a lot.
I have attached a
On 6/17/2010 7:48 AM, Sunil Mushran wrote:
On 06/17/2010 01:35 AM, Srinivas Eeda wrote:
On 6/17/2010 1:32 AM, Joel Becker wrote:
On Wed, Jun 16, 2010 at 06:44:43PM -0700, Sunil Mushran wrote:
One way to skip a lockres in the purgelist is to list_del_init() and
list_add_tail(). That
Sunil,
as of now, there is still a window in dlm_get_lock_resource, where it
finds the lockres but it doesn't protect it from getting purged. Second
patch fixes this by marking it in_use, can you please review that one as
well.
Thanks,
--Srini
On 6/17/2010 8:06 AM, Sunil Mushran wrote:
On
On Thu, Jun 17, 2010 at 07:48:38AM -0700, Sunil Mushran wrote:
On 06/17/2010 01:35 AM, Srinivas Eeda wrote:
On 6/17/2010 1:32 AM, Joel Becker wrote:
As far as I can tell from reading the code, the time_after()
check is because they are time ordered. Wouldn't moving it to the end
violate
We don't have to update the last used to move it to tail. If it is
now in use, means it is about to be taken out of the purgelist. We
just need to move it from our way for the time being.
On Jun 17, 2010, at 9:55 AM, Srinivas Eeda srinivas.e...@oracle.com
wrote:
On 6/17/2010 7:48 AM,
On 10-06-17 08:06, Sunil Mushran wrote:
On 06/15/2010 11:06 PM, Wengang Wang wrote:
still the question.
If you have sent DEREF request to the master, and the lockres became in-use
again, then the lockres remains in the hash table and also in the purge list.
So
1) If this node is the last
still the question.
If you have sent DEREF request to the master, and the lockres became in-use
again, then the lockres remains in the hash table and also in the purge list.
So
1) If this node is the last ref, there is a possibility that the master
purged the lockres after receiving DEREF request
On Tue, Jun 15, 2010 at 09:43:02PM -0700, Srinivas Eeda wrote:
There are two problems in dlm_run_purgelist
1. If a lockres is found to be in use, dlm_run_purgelist keeps trying to purge
the same lockres instead of trying the next lockres.
2. When a lockres is found unused,
15 matches
Mail list logo
