From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Changwei Ge <chge@linux.alibaba.com>, Kai Li <li.kai4@h3c.com>,
mark@fasheh.com, jlbec@evilplan.org
Cc: ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org
Subject: [Ocfs2-devel] [PATCH] ocfs2: call journal flush to mark journal as empty after journal recovery when mount
Date: Thu, 12 Dec 2019 13:51:45 +0800 [thread overview]
Message-ID: <5510650e-2e5d-2f7c-e1ef-b118389125d5@linux.alibaba.com> (raw)
In-Reply-To: <5bc88eee-21d9-14c2-6544-d4e3baa931cb@linux.alibaba.com>
On 19/12/12 11:55, Changwei Ge wrote:
> Hi Joseph,
>
> On 12/11/19 9:17 PM, Joseph Qi wrote:
>>
>>
>> On 19/12/11 18:03, Kai Li wrote:
>>> If journal is dirty when mount, it will be replayed but jbd2 sb
>>> log tail cannot be updated to mark a new start because
>>> journal->j_flag has already been set with JBD2_ABORT first
>>> in journal_init_common. When a new transaction is committed, it
>>> will be recored in block 1 first(journal->j_tail is set to 1 in
>>> journal_reset).
>>>
>>> If emergency restart happens again before journal super block is
>>> updated unfortunately, the new recorded trans will not be replayed
>>> in the next mount.
>>>
>> I think I've finally understood the problem. But I don't think it has
>> been clearly described for reviewing. I strongly suggest you describe
>> the problem in the way of timeline, such as in which step, do what
>> operation, and what is the status, etc.
>>
>>
>>> This exception happens when this lun is used by only one node. If it
>>> is used by multi-nodes, other node will replay its journal and its
>>> journal sb block will be updated after recovery.
>>>
>>> To fix this problem, use jbd2_journal_flush to mark journal as empty as
>>> ocfs2_replay_journal has done.>
>> Sounds reasonable. But IMO, it is really a corner use scenario, using
>> cluster filesystem in single node...
>
> True, this use case should be rare.
> But considering that fixing this is not complicated and does no harm at least, I am inclining taking this in. We can only merge it to mainline rather than -stable branches. :-)
>
Okay, let's move it on.
Thanks,
Joseph
WARNING: multiple messages have this Message-ID (diff)
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Changwei Ge <chge@linux.alibaba.com>, Kai Li <li.kai4@h3c.com>,
mark@fasheh.com, jlbec@evilplan.org
Cc: ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ocfs2: call journal flush to mark journal as empty after journal recovery when mount
Date: Thu, 12 Dec 2019 13:51:45 +0800 [thread overview]
Message-ID: <5510650e-2e5d-2f7c-e1ef-b118389125d5@linux.alibaba.com> (raw)
In-Reply-To: <5bc88eee-21d9-14c2-6544-d4e3baa931cb@linux.alibaba.com>
On 19/12/12 11:55, Changwei Ge wrote:
> Hi Joseph,
>
> On 12/11/19 9:17 PM, Joseph Qi wrote:
>>
>>
>> On 19/12/11 18:03, Kai Li wrote:
>>> If journal is dirty when mount, it will be replayed but jbd2 sb
>>> log tail cannot be updated to mark a new start because
>>> journal->j_flag has already been set with JBD2_ABORT first
>>> in journal_init_common. When a new transaction is committed, it
>>> will be recored in block 1 first(journal->j_tail is set to 1 in
>>> journal_reset).
>>>
>>> If emergency restart happens again before journal super block is
>>> updated unfortunately, the new recorded trans will not be replayed
>>> in the next mount.
>>>
>> I think I've finally understood the problem. But I don't think it has
>> been clearly described for reviewing. I strongly suggest you describe
>> the problem in the way of timeline, such as in which step, do what
>> operation, and what is the status, etc.
>>
>>
>>> This exception happens when this lun is used by only one node. If it
>>> is used by multi-nodes, other node will replay its journal and its
>>> journal sb block will be updated after recovery.
>>>
>>> To fix this problem, use jbd2_journal_flush to mark journal as empty as
>>> ocfs2_replay_journal has done.>
>> Sounds reasonable. But IMO, it is really a corner use scenario, using
>> cluster filesystem in single node...
>
> True, this use case should be rare.
> But considering that fixing this is not complicated and does no harm at least, I am inclining taking this in. We can only merge it to mainline rather than -stable branches. :-)
>
Okay, let's move it on.
Thanks,
Joseph
next prev parent reply other threads:[~2019-12-12 5:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 10:03 [Ocfs2-devel] [PATCH] ocfs2: call journal flush to mark journal as empty after journal recovery when mount Kai Li
2019-12-11 10:03 ` Kai Li
2019-12-11 12:47 ` [Ocfs2-devel] " Changwei Ge
2019-12-11 12:47 ` Changwei Ge
2019-12-12 2:27 ` [Ocfs2-devel] " Likai
2019-12-12 2:27 ` Likai
2019-12-11 13:17 ` [Ocfs2-devel] " Joseph Qi
2019-12-11 13:17 ` Joseph Qi
2019-12-12 3:43 ` [Ocfs2-devel] " Likai
2019-12-12 3:43 ` Likai
2019-12-12 3:55 ` [Ocfs2-devel] " Changwei Ge
2019-12-12 3:55 ` Changwei Ge
2019-12-12 5:51 ` Joseph Qi [this message]
2019-12-12 5:51 ` Joseph Qi
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=5510650e-2e5d-2f7c-e1ef-b118389125d5@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=chge@linux.alibaba.com \
--cc=jlbec@evilplan.org \
--cc=li.kai4@h3c.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.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.