On Wed, 29 Jan 2020 15:28:37 -0500 "Valdis Klētnieks" <valdis.kletnieks@xxxxxx> wrote: > [...] > > Questions for Lukas: > > First off, see my comment about -EIO. Do you have plans for an ioctl or > other way for userspace to get the two checksums so diagnostic programs > can do better error diagnosis/recovery? Not really, but as I will integrate it with the existing dm-integrity infrastructure it will support the recovery mode which won't check the checksums. Recovery will more or less happen as you described it above. > If I understand what you're doing, each 4096 (or whatever) block will actually > take (4096 + 2* checksum size) bytes, which means each logical consecutive > block will be offset from the start of a physical block by some amount. This > effectively means that you are guaranteed one read-modify-write and possibly > two, for each write. (The other alternative is to devote an entire block to > each checksum, but that triples the size and at that point you may as well just > do a 2+1 raidset) No, csum_next (and csum_prev) is a whole sector (i.e. physical block) containing all the checksums for the following chunk of data (which spans multiple sectors), so pretty similar to the current dm-integrity implementation apart from the 2nd checksum sector. RMW is only needed for the checksum sector and because they don't take up much space, they are easily cached in ram so only needing the write in the best case. Regarding the ordering guarantee, I have now gathered that the kernel will happily split the bio if the size is not optimal for the hardware which means it's not guaranteed - right? _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
