From: piaojun <piaojun@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: checkpoint appending truncate log transaction before flushing
Date: Fri, 15 Feb 2019 17:21:07 +0800 [thread overview]
Message-ID: <5C668483.5050501@huawei.com> (raw)
In-Reply-To: <63ADC13FD55D6546B7DECE290D39E373012785431C@H3CMLB14-EX.srv.huawei-3com.com>
Hi Changwei,
I just need more time to review this.
Thanks,
Jun
On 2019/2/15 16:27, Changwei Ge wrote:
> Hi Jun,
>
> Do you have any other question, advise or concern?
> I am expecting an explicit feedback(ack/nack) if you already understand the problem and my way fixing it.
>
> Thanks,
> Changwei
>
> On 2019/2/14 18:25, Changwei Ge wrote:
>> On 2019/2/14 18:06, piaojun wrote:
>>> Hi Changwei,
>>>
>>> On 2019/2/14 16:53, Changwei Ge wrote:
>>>> Hi Jun,
>>>>
>>>> Thanks for looking into this :-)
>>>>
>>>> On 2019/2/14 16:24, piaojun wrote:
>>>>> Hi Changwei,
>>>>>
>>>>> On 2019/2/14 12:03, Changwei Ge wrote:
>>>>>> Appending truncate log(TA) and and flushing truncate log(TF) are
>>>>>> two separated transactions. They can be both committed but not
>>>>>> checkpointed. If crash occurs then, both two transaction will be
>>>>>> replayed with several already released to global bitmap clusters.
>>>>>
>>>>> Do you mean that both the two transactions will release cluster to
>>>>> global bitmap? But I think the TA won't give back clusters to global
>>>>> bitmap.
>>>>>
>>>>
>>>> No, I don't mean that both TA and TF are releasing clusters to global bitmap.
>>>>
>>>> But consideration into clusters reclaim , clusters will first be recorded in truncate
>>>> log and then be returned to global bitmap, which involves TA and TF jdb2/transactions.
>>>>
>>>> TA's job is to append cluster records to truncate log, by which we can overcome a potential space leak problem.
>>>> TF's job is to return clusters to global bitmap.
>>>>
>>>> It's possible that TA and TF are both committed to JBD but sadly none of them is check-pointed.
>>>> So journal replaying need to replay both TA and TF during next mount.
>>>> Then there is a record residing in truncate log representing the already released cluster
>>>> which has been returned to global bitmap by replaying TF.
>>>>
>>>> Now the double free shows up.
>>>
>>> Do you mean that when mount again, truncate log recovery will find
>>> record residing in truncate log which already released? But after the
>>> TF transaction replayed during mount, truncate log won't be recovered
>>> as tl->tl_used is less than tl->tl_count.
>>
>> Um, not just truncate log relaying but also involves a jbd2 transaction recording its last append operation.
>> That operation may meet the flush condition (ocfs2_truncate_log_needs_flush)
>>
>> Thanks,
>> Changwei
>>
>>>
>>> Thanks,
>>> Jun
>>>
>>>>
>>>>
>>>>>> Then truncate log will be replayed resulting in cluster double free.
>>>>>
>>>>> Does this problem only cause some error log? As below:
>>>>>
>>>>> ocfs2_replay_truncate_records
>>>>> ocfs2_free_clusters
>>>>> _ocfs2_free_clusters
>>>>> _ocfs2_free_suballoc_bits
>>>>> ocfs2_block_group_clear_bits
>>>>> "Trying to clear %u bits at offset %u in group descriptor"
>>>>>
>>>>
>>>> Exactly, when the issue occurs, it will be printed as above.
>>>>
>>>> Thanks,
>>>> Changwei
>>>>
>>>>> Thanks,
>>>>> Jun
>>>>>
>>>>>>
>>>>>> To reproduce this issue, just crash the host while punching hole to files.
>>>>>>
>>>>>> Signed-off-by: Changwei Ge <ge.changwei@h3c.com>
>>>>>> ---
>>>>>> fs/ocfs2/alloc.c | 15 +++++++++++++++
>>>>>> 1 file changed, 15 insertions(+)
>>>>>>
>>>>>> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
>>>>>> index d1cbb27..29bc777 100644
>>>>>> --- a/fs/ocfs2/alloc.c
>>>>>> +++ b/fs/ocfs2/alloc.c
>>>>>> @@ -6007,6 +6007,7 @@ int __ocfs2_flush_truncate_log(struct ocfs2_super *osb)
>>>>>> struct buffer_head *data_alloc_bh = NULL;
>>>>>> struct ocfs2_dinode *di;
>>>>>> struct ocfs2_truncate_log *tl;
>>>>>> + struct ocfs2_journal *journal = osb->journal;
>>>>>>
>>>>>> BUG_ON(inode_trylock(tl_inode));
>>>>>>
>>>>>> @@ -6027,6 +6028,20 @@ int __ocfs2_flush_truncate_log(struct ocfs2_super *osb)
>>>>>> goto out;
>>>>>> }
>>>>>>
>>>>>> + /* Appending truncate log(TA) and and flushing truncate log(TF) are
>>>>>> + * two separated transactions. They can be both committed but not
>>>>>> + * checkpointed. If crash occurs then, both two transaction will be
>>>>>> + * replayed with several already released to global bitmap clusters.
>>>>>> + * Then truncate log will be replayed resulting in cluster double free.
>>>>>> + */
>>>>>> + jbd2_journal_lock_updates(journal->j_journal);
>>>>>> + status = jbd2_journal_flush(journal->j_journal);
>>>>>> + jbd2_journal_unlock_updates(journal->j_journal);
>>>>>> + if (status < 0) {
>>>>>> + mlog_errno(status);
>>>>>> + goto out;
>>>>>> + }
>>>>>> +
>>>>>> data_alloc_inode = ocfs2_get_system_file_inode(osb,
>>>>>> GLOBAL_BITMAP_SYSTEM_INODE,
>>>>>> OCFS2_INVALID_SLOT);
>>>>>>
>>>>>
>>>> .
>>>>
>>>
>>
>> _______________________________________________
>> Ocfs2-devel mailing list
>> Ocfs2-devel at oss.oracle.com
>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>>
> .
>
next prev parent reply other threads:[~2019-02-15 9:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 4:03 [Ocfs2-devel] [PATCH] ocfs2: checkpoint appending truncate log transaction before flushing Changwei Ge
2019-02-14 8:24 ` piaojun
2019-02-14 8:53 ` Changwei Ge
2019-02-14 10:06 ` piaojun
2019-02-14 10:23 ` Changwei Ge
2019-02-15 8:27 ` Changwei Ge
2019-02-15 9:21 ` piaojun [this message]
2019-09-16 1:41 ` 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=5C668483.5050501@huawei.com \
--to=piaojun@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox