[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTinLqWgsJjt=AfVnM8_aK9DGMkzcDQ@mail.gmail.com>
Date: Wed, 27 Apr 2011 08:52:32 +0800
From: Ding Dinghua <dingdinghua85@...il.com>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Niraj Kulkarni <kulkarniniraj14@...il.com>,
Yongqiang Yang <xiaoqiangnk@...il.com>,
linux-ext4@...r.kernel.org
Subject: Re: Need of revoke mechanism in JBD
Oh, here no-journalled-data is misleading, I mean mount in
data=writeback mode or data=ordered mode,
not in data=journal mode.
2011/4/27 Andreas Dilger <adilger@...ger.ca>:
> On 2011-04-26, at 4:47 AM, Niraj Kulkarni wrote:
>> If I am thinking correctly, journal would be checkpointed on
>> filesystem unmount calls.
>> This implies the given scenario would be pretty rare.
>>
>> ie first filesystem should be mounted in full-journal mode, and
>> crashed prior to checkpoint.
>> then it should be remounted in no-journalled-data mode without
>> recovery and again remounted in full journalled mode with recovery.
>
> It shouldn't be possible to mount the filesystem in no-journal mode
> without doing journal recovery. The filesystem sets an INCOMPAT_RECOVER
> flag when the journal has any transactions in it, and the journal should
> be replayed before the filesystem is finished mounting.
>
> Looking at ext4_fill_super() the "noload" mount option is used to avoid
> loading the journal even if there is a journal (COMPAT_HAS_JOURNAL is set),
> but if INCOMPAT_RECOVER is set the filesystem will refuse to mount.
>
>
>> On Tuesday 26 April 2011 02:53 PM, Ding Dinghua wrote:
>>> I think it's not only a performance issue but more important, a
>>> correctness issue.
>>> Revoke table is used for preventing the wrong replay of journal which
>>> cause data corruption:
>>> If block A has been journalled its modification, committed to journal
>>> and hasn't been checkpointed,
>>> and in later transactions block A is freed and reused for data in
>>> no-journalled-data mode, then If
>>> we don't have revoke table which recording the releasing event, replay
>>> of journal will overwrite the new data,
>>> which causing data corruption.
>>>
>>> 2011/4/26 Yongqiang Yang<xiaoqiangnk@...il.com>:
>>>> AFAIK, it can accelerate the recovering process. If a block is in the
>>>> revoke table of a transaction t1 and t1 is committed, then the there
>>>> is no need to recover the block in transactions which is earlier than
>>>> t1.
>>>>
>>>> On Tue, Apr 26, 2011 at 4:29 PM, Niraj Kulkarni
>>>> <kulkarniniraj14@...il.com> wrote:
>>>>> Hi all,
>>>>> I am new to fs development. I am trying to modify the journal structure
>>>>> of JBD. While analyzing the code, I could understand most of the things, but
>>>>> I am not able to understand the need of revoke mechanism. Can anybody
>>>>> enlighten me on this issue?
>>>>>
>>>>> Regards
>>>>> Niraj
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>>> the body of a message to majordomo@...r.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes
>>>> Yongqiang Yang
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Cheers, Andreas
>
>
>
>
>
>
--
Ding Dinghua
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists