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
