linux-ext4 - Re: Need of revoke mechanism in JBD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTikJpb8je2UUXhav6rAF7UKaMc6KjQ@mail.gmail.com>
Date:	Tue, 26 Apr 2011 13:57:48 +0300
From:	Amir Goldstein <amir73il@...il.com>
To:	Niraj Kulkarni <kulkarniniraj14@...il.com>
Cc:	Ding Dinghua <dingdinghua85@...il.com>,
	Yongqiang Yang <xiaoqiangnk@...il.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Need of revoke mechanism in JBD

On Tue, Apr 26, 2011 at 1:47 PM, Niraj Kulkarni
<kulkarniniraj14@...il.com> 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.
>
> Am I thinking on correct lines?

nope.
first the block is allocated as metadata and journaled.
then the metadata block is freed and re-allocated as non-journaled data.
this is the use case and it would be very easy to corrupt data if it wasn't
for journal revoke.

Amir.

>
> 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
>
--
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