All of lore.kernel.org
 help / color / mirror / Atom feed
From: jiangyiwen <jiangyiwen@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: fix panic due to unrecovered local alloc
Date: Mon, 19 Nov 2018 19:17:18 +0800	[thread overview]
Message-ID: <5BF29BBE.3040105@huawei.com> (raw)
In-Reply-To: <128c905f-8812-36fd-0808-01f653685495@oracle.com>

On 2018/11/19 15:15, Junxiao Bi wrote:
> On 11/19/18 1:54 PM, jiangyiwen wrote:
> 
>> On 2018/11/19 11:24, Junxiao Bi wrote:
>>> Hi Yiwen
>>>
>>> On 11/19/18 10:17 AM, jiangyiwen wrote:
>>>> Hi Junxiao,
>>>>
>>>> I think this scenario may be as follows:
>>>>
>>>> ocfs2_dismount_volume()
>>>>     - ocfs2_shutdown_local_alloc()
>>>>       1. clear local alloc and commit transaction
>>> For jbd2, not commit yet, it could be still in running transaction, that means it was not written into journal yet.
>>>
>>> Later when flushing the running transaction to journal, io error may happen, this running transaction not only contained local alloc changes but also other metadata. How recovering local alloc only can avoid other metadata corruption?
>>>
>> Right, so we should judge if journal abort when call ocfs2_journal_toggle_dirty().
> 
> jbd2_journal_destroy() already did that, if is_journal_aborted() return true, it will reutrn -EIO, so seemed checking the return value enough to detect this?
> 
> Thanks,
> 
> Junxiao.
> 

You're right, jbd2_journal_destroy already check journal aborted.

> 
>>
>>>>       2. storage disconnection cause data don't update to disk and journal abort.
>>>>     - ocfs2_journal_shutdown()
>>>>       3. in this function, it will call ocfs2_journal_toggle_dirty() to
>>>>          clear dirty even if journal abort.
>>> Check rerturn value of jbd2_journal_destroy() seemed OK to judge whether toggle dirty flag.
>>>
>> I suggest add the judgement of journal_abort too, like ext4_put_super().
>>
>> Thanks.
>>
>>> Thanks,
>>>
>>> Junxiao.
>>>
>>>> So I suggest we can do two aspects:
>>>> 1. Actively recover local alloc when checking journal clean and "local_alloc dirty"
>>>> in ocfs2_check_volume(), instead of fsck, it can online recover this case more
>>>> intelligently.
>>>> 2. Before calling ocfs2_journal_toggle_dirty(), check if journal abort.
>>>>
>>>> Thanks,
>>>> Yiwen.
>>>>
>>>
>>
> 
> 

      reply	other threads:[~2018-11-19 11:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-16  7:33 [Ocfs2-devel] [PATCH] ocfs2: fix panic due to unrecovered local alloc Junxiao Bi
2018-11-19  0:54 ` piaojun
2018-11-19  1:35   ` Junxiao Bi
2018-11-19  1:52     ` piaojun
2018-11-19  2:12       ` Junxiao Bi
2018-11-19  2:17 ` jiangyiwen
2018-11-19  3:24   ` Junxiao Bi
2018-11-19  5:54     ` jiangyiwen
2018-11-19  7:15       ` Junxiao Bi
2018-11-19 11:17         ` jiangyiwen [this message]

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=5BF29BBE.3040105@huawei.com \
    --to=jiangyiwen@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.