Re: Jbd2 async problem
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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Jbd2 async problem
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. pgpwXfHW3krou.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Jbd2 async problem
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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
