I am trying to understand the behaviour of jbd2 journaling when one of the many transactions that are written to the journal gets corrupted.
As per my understanding, for a write operation, first a write is done to persist data to the on-disk location, followed by the corresponding metadata transaction write on the journal. The format of metadata updates is as follows - 1) transaction descriptor block 2) the metadata blocks and 3) the transaction commit block. This continues for multiple transactions. Finally during a checkpoint, the metadata corresponding to these transactions are written to the on-disk location.
I also understand that order needs to be maintained between transactions during replay if the file system crashed before checkpoint occurred. i.e. if we have 3 transactions T1, T2, T3, they will be replayed sequentially. This is to avoid the scenario where overwrites of the same block occur or there is delete and subsequent re-allocation of the same block in two consecutive transactions.
My question is for a special case: where T1, T2, and T3 being three consecutive transactions, if T1 and T3 maintain metadata change for say M1 metadata block, and T2 stores metadata change for M2 block. and M1 and M2 are not at all overlapping, in that case, if T2 gets corrupted, will T3 and all subsequent transactions be discarded?
