Ordering guarantee inside a single bio?

[Lukas Straub]

On Wed, 29 Jan 2020 15:28:37 -0500
"Valdis Klētnieks" <valdis.kletnieks at vt.edu> 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?