Hello Jan, thanks for suggestions.
On 2023/1/26 18:14, Jan Kara wrote:
> Hello!
>
> On Thu 19-01-23 11:45:59, Zhang Yi wrote:
>> From: Zhang Yi <yi.zhang@xxxxxxxxxx>
>>
>> For a newly mounted file system, the journal committing thread always
>> record log from the beginning of the journal area, no matter whether the
>> journal is clean or it has just been recovered. It is disadvantageous to
>> analysis corrupted file system image and locate the file system
>> inconsistency bugs. When we get a corrupted file system image and want
>> to find out what has happened, besides lookup the system log, one
>> effective may is to backtrack the journal log. But we may not always run
>> e2fsck before each mount and the default fsck -a mode also cannot always
>> find all inconsistencies, so it could left over some inconsistencies
>> into the next mount until we detect it. Finally, the transactions in the
>> journal may probably discontinuous and some relatively new transactions
>> has been covered, it becomes hard to analyse. So if we could records
>> transactions continuously between each mounts, we could acquire more
>> useful info from the journal.
>>
>> |Previous mount checkpointed/recovered logs|Current mount logs |
>> |{------}{---}{--------} ... {------}| ... |{======}{========}...000000|
>>
>> This patch save the head blocknr in the superblock after flushing the
>> journal or unmounting the file system, let the next mount could continue
>> to record new transaction behind it. This change is backward compatible
>> because the old kernel does not care about the head blocknr of the
>> journal. It is also fine if we mount a clean old image without valid
>> head blocknr, we fail back to set it to s_first just like before.
>> Finally, for the case of mount an unclean file system, we could also get
>> the journal head easily after scanning the journal, it will continue to
>> record new transaction after the recovered transactions.
>
> I understand the usecase although if there are multiple mounts between
> the time when the corruption happened and when it got detected I suspect
> the journal will be already overwritten (filled and wrapped over) and so not
> too useful anyway. But still the number of blocks preserved in the journal
> will be higher so I guess there is some chance there will be something
> useful in there.
>
> Do you want this mostly for debugging stuff (like fuzzer testing) or
> would you really want to run with this on production machines?
It's useful for debugging stuff, but it may also benefit to our production
machines (e.g. we have many consumer products and embedded products that are
not long running and have not too much filesystem changes for each running
and mount), so I really want to run with this on production machines
if possible.
>
> Also I think we could actually implement something like this without adding
> s_head field (i.e., without any on-disk format change). Setting of s_start
> to 0 when the journal is empty is actually only an optimization. We could
> leave it where it is (in this debug mode), just make jbd2 detect empty
> journal while it is used from j_head == s_start instead of by testing
> s_start == 0, and the only difference would be that jbd2_journal_recover()
> would now try recovering even empty journal (but abort immediately) which
> mostly should not happen on clean mount anyway because we call jbd2 to
> recover the journal only if ext4_has_feature_journal_needs_recovery().
>
I understand it's best to avoid changing the on-disk format. But IIUC, I think
this is not backward compatible, it changes the 'magic code' (s_start==0) of a
clean journal, the old kernel use it. If we mount a clean ext4 image in old
kernel which has been just worked in debug mode, below warning in
jbd2_journal_wipe() appears, and the fsck also complain about it.
JBD2: Clearing recovery information on journal
fsck.ext4 -a /dev/pmem1
/dev/pmem1: Superblock needs_recovery flag is clear, but journal has data.
/dev/pmem1: Run journal anyway.
/dev/pmem1: recovering journal
...
Although it is not a big stuff, but it looks strange and confused. For this
reason, it seems that this (reuse s_start) may only used for debugging stuff
if we don't care about this incompatible warning. Or else we make things
complicated, we may have to add one more incompatible feature bit for this
mode and we cannot mount it in old kernels. What do you think?
Thanks.
Yi.
