From: Joel Becker <Joel.Becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/2] ocfs2 fix o2dlm dlm run purgelist
Date: Thu, 17 Jun 2010 12:28:06 -0700 [thread overview]
Message-ID: <20100617192805.GA7981@mail.oracle.com> (raw)
In-Reply-To: <4C1A35C6.1060705@oracle.com>
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 that?
> >right. that's why I didn't want to move used lockres to tail :)
>
>
> No. There is no need for time ordering. Or, am I missing something?
>
> We delay the purge incase the file system changes its mind and wants
> to reuse it. By delaying, we hold onto the mastery information. That's it.
The comment is right there:
/* Since resources are added to the purge list
* in tail order, we can stop at the first
* unpurgable resource -- anyone added after
* him will have a greater last_used value */
break;
So we're going to break out of this loop as soon we see a later time.
Anything you've moved to the back will be ignored until enough time
passes that the things in front of it are candidates for purge.
You could, of course, just change the 'break' to a 'continue'
and find those, but I kind of like the short-circuit behavior. I don't
know how long this list is, but walking a whole bunch of "not yet"
lockreses just to hopefully find one at the end seems silly.
I think it is better to leave the busy ones at the front of the
list and just walk past them if they can't be dealt with now.
Joel
--
Life's Little Instruction Book #157
"Take time to smell the roses."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2010-06-17 19:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 4:43 [Ocfs2-devel] [PATCH 1/2] ocfs2 fix o2dlm dlm run purgelist Srinivas Eeda
2010-06-16 4:43 ` [Ocfs2-devel] [PATCH 2/2] ocfs2: o2dlm fix race in purge lockres and newlock (orabug 9094491) Srinivas Eeda
2010-06-18 2:11 ` Sunil Mushran
2010-06-18 16:32 ` Srinivas Eeda
2010-06-16 6:06 ` [Ocfs2-devel] [PATCH 1/2] ocfs2 fix o2dlm dlm run purgelist Wengang Wang
2010-06-17 8:53 ` Srinivas Eeda
2010-06-17 11:05 ` Wengang Wang
2010-06-17 15:06 ` Sunil Mushran
2010-06-17 16:56 ` Srinivas Eeda
2010-06-18 2:37 ` Wengang Wang
2010-06-18 16:37 ` Sunil Mushran
2010-06-21 1:40 ` Wengang Wang
2010-06-17 1:39 ` Joel Becker
2010-06-17 8:32 ` Srinivas Eeda
2010-06-17 9:08 ` Joel Becker
2010-06-17 1:44 ` Sunil Mushran
2010-06-17 6:05 ` Wengang Wang
2010-06-17 8:32 ` Joel Becker
2010-06-17 8:35 ` Srinivas Eeda
2010-06-17 14:48 ` Sunil Mushran
2010-06-17 16:55 ` Srinivas Eeda
2010-06-17 19:31 ` Sunil Mushran
2010-06-17 19:28 ` Joel Becker [this message]
2010-06-17 23:34 ` Sunil Mushran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100617192805.GA7981@mail.oracle.com \
--to=joel.becker@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).