Jbd2 async problem

Jbd2 async problem

[Rock Lee]

Hi:

I am working on jbd2 with checksum v3, trying to learn something from
the async feature. However, when I read the replay process in
do_one_process(), I got a little confused.

When async is on, commit blocks have the chance to reach the disk
before metadata blocks(which are on BJ_Shadow). If just at this
moment, power cutting occurs. Next mount time, we have to recovery
journal. Since checksum v3 is been chosen, metadata could be copyed to
filesystem one by one, if the metadata block has the right crc value.
But in the scenario I described before, commit block may reached disk
before some metadata blocks in a transaction. Current jbd2 code(linux
4.15) just skips those metadata blocks which have no correct crc, and
still copies the metadata blocks with the right crc.

I think in order to keep the consistency, the whole transaction should
be discarded, as long as not all the metadata blocks have the right
crc value in the transaction. But why jbd2 still copies the metadata
block(with the right crc) to filesystem when bad crc metadata blocks
exist ?

I will appreciate it if you could help me.

-- 
Cheers,
Rock

Jbd2 async problem

[valdis.kletnieks at vt.edu]

On Mon, 22 Jan 2018 20:18:47 +0800, Rock Lee said:

> I think in order to keep the consistency, the whole transaction should
> be discarded, as long as not all the metadata blocks have the right
> crc value in the transaction. But why jbd2 still copies the metadata
> block(with the right crc) to filesystem when bad crc metadata blocks
> exist ?

Consider the case of 75 metadata blocks in the journal, with one bad block.

Which results in less total damage when the journal is replayed:

1) Applying the 74 good ones (if possible) and complain about the one bad one?

2) Refusing to deal with *any* of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180122/be6e2e9f/attachment.sig>

Jbd2 async problem

[Rock Lee]

Hi:

> Consider the case of 75 metadata blocks in the journal, with one bad block.
>
> Which results in less total damage when the journal is replayed:
>
> 1) Applying the 74 good ones (if possible) and complain about the one bad one?
>
> 2) Refusing to deal with *any* of them.

Indeed, I would like to choose 1) to keep my filesystem from less
damage. However, a transaction means the whole operation is atomic, it
could not be seperated in replay. If bad blocks could just be ignore,
there's no need of descriptor + commit pair, just copy crc right
blocks back to filesystem could achieve our goals.

-- 
Cheers,
Rock