From: Joseph Qi <joseph.qi@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] ocfs2: Question for ocfs2_recovery_thread
Date: Mon, 20 May 2013 10:49:11 +0800 [thread overview]
Message-ID: <51998F27.7070601@huawei.com> (raw)
In-Reply-To: <51983831.3050802@huawei.com>
On 2013/5/19 10:25, Joseph Qi wrote:
> On 2013/5/18 21:26, Sunil Mushran wrote:
>> The first node that gets the lock will do the actual recovery. The others will get the lock and see a clean journal and skip the recovery. A thread should never error out if it fails to get the lock. It should try and try again.
>>
>> On May 17, 2013, at 11:27 PM, Joseph Qi <joseph.qi@huawei.com> wrote:
>>
>>> Hi,
>>> Once there is node down in the cluster, ocfs2_recovery_thread will be
>>> triggered on each node. These threads then do the down node recovery by
>>> get super lock.
>>> I have several questions on this:
>>> 1) Why each node has to run such a thread? We know at last one node can
>>> get the super lock and do the actual recovery.
>>> 2) If this thread is running but something error occurred, take
>>> ocfs2_super_lock failed for example, the thread will exit without
>>> clearing recovery map, will it cause other threads still waiting for
>>> recovery in ocfs2_wait_for_recovery?
>>>
>>
>>
> But when error occurs and goes to bail, and the restart logic will not
> run. Codes like below:
> ...
> status = ocfs2_wait_on_mount(osb);
> if (status < 0) {
> goto bail;
> }
>
> rm_quota = kzalloc(osb->max_slots * sizeof(int), GFP_NOFS);
> if (!rm_quota) {
> status = -ENOMEM;
> goto bail;
> }
> restart:
> status = ocfs2_super_lock(osb, 1);
> if (status < 0) {
> mlog_errno(status);
> goto bail;
> }
> ...
> if (!status && !ocfs2_recovery_completed(osb)) {
> mutex_unlock(&osb->recovery_lock);
> goto restart;
> }
>
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>
>
One more question, do we make sure dlm_recovery_thread always prior to
ocfs2_recovery_thread?
next prev parent reply other threads:[~2013-05-20 2:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-18 6:27 [Ocfs2-devel] ocfs2: Question for ocfs2_recovery_thread Joseph Qi
2013-05-18 13:26 ` Sunil Mushran
2013-05-19 2:25 ` Joseph Qi
2013-05-20 2:49 ` Joseph Qi [this message]
2013-05-22 23:00 ` Sunil Mushran
2013-05-23 9:37 ` shencanquan
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=51998F27.7070601@huawei.com \
--to=joseph.qi@huawei.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.