From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/2] Introduce ocfs2_recover_node
Date: Thu, 02 Dec 2010 11:05:01 -0800 [thread overview]
Message-ID: <4CF7EDDD.9020202@oracle.com> (raw)
In-Reply-To: <20101202052945.GG16604@mail.oracle.com>
On 12/01/2010 09:29 PM, Joel Becker wrote:
> On Wed, Nov 17, 2010 at 09:50:04AM -0600, Goldwyn Rodrigues wrote:
>> @@ -1470,7 +1451,11 @@ void ocfs2_recovery_thread(struct ocfs2_super
>> *osb, int node_num)
>>
>> /* People waiting on recovery will wait on
>> * the recovery map to empty. */
>> - if (ocfs2_recovery_map_set(osb, node_num))
>> + ret = ocfs2_recovery_node_set(osb, node_num);
>> + if (ret == -ENOMEM) {
>> + mlog_errno(ret);
>> + goto out;
>> + } else if (ret)
>> mlog(0, "node %d already in recovery map.\n", node_num);
> This is a broken change. If we get -ENOMEM, we won't block
> other processes. We can't have that happen. There are two possible
> solutions. First, like Sunil said, we can preallocate max_slots recovery
> entries. Seems pretty sane. The other solution would be to set an
> in-recovery flag that others can check, so even when the recovery list
> is empty because of a failed allocation, other processes still block. I
> prefer the preallocation because it doesn't fail recovery.
You could stick with the list but preallocate max_slots items during init.
Attach all those to the s_init_reco_list. During set, move a item to
s_active_reco_list. Clear moves it back.
next prev parent reply other threads:[~2010-12-02 19:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 15:50 [Ocfs2-devel] [PATCH 1/2] Introduce ocfs2_recover_node Goldwyn Rodrigues
2010-12-02 4:49 ` Sunil Mushran
2010-12-02 5:29 ` Joel Becker
2010-12-02 19:05 ` Sunil Mushran [this message]
2010-12-02 23:49 ` Joel Becker
-- strict thread matches above, loose matches on Subject: below --
2010-11-16 22:59 Goldwyn Rodrigues
2010-11-17 1:49 ` Wengang Wang
2010-11-17 2:00 ` Wengang Wang
2010-11-17 2:04 ` Wengang Wang
2010-11-12 1:01 Goldwyn Rodrigues
2010-11-12 2:16 ` Wengang Wang
2010-11-12 19:22 ` Goldwyn Rodrigues
2010-11-13 5:03 ` Wengang Wang
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=4CF7EDDD.9020202@oracle.com \
--to=sunil.mushran@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.