Re: [PATCH 2/2] block: handle REQ_OP_ZONE_APPEND in __bio_integrity_action

["Martin K. Petersen" <martin.petersen@oracle.com>]

Caleb,

> Right, I don't mean partitions of zoned devices, but block devices in
> general. I was just trying to understand why the remapping
> infrastructure exists in the first place. Seems like we can't remove
> it entirely, but we can at least ensure the ref tag seeds are correct
> if it's skipped for a non-partitioned device.

The entity attaching the PI to the I/O decides what the seed value
should be.

If you are an application preparing PI, you don't know which LBA a write
is eventually going to end up at. You just know you are writing block 10
inside your file. So you generate PI starting with a reference tag value
of 10 because that is what makes sense to you. And thus you set the seed
to 10 to tell the remapping code which initial reference tag value to
expect in the prepared PI buffer.

Once the write hits the bottom of the stack, we know which initial
reference tag the hardware expects. So we remap the reference tags in
the PI buffer from whatever made sense to the application to whatever
the hardware requires. I.e. an initial value of the lower 32 bits of the
LBA for T10 PI Type 1, incremented by 1 for each subsequent protection
interval.

For reads, it's the same thing. The application wants to read starting
at block offset 10 inside the file so it sets the seed value to 10. At
the bottom of the stack we know how to interpret the PI returned by the
hardware. So we validate that the reference tags received from the
controller match the lower 32 bits of the LBA or whatever the correct PI
format is. And then we remap the reference tags in the received PI
buffer, setting the reference tag to the requested value of 10 for the
first block, and then incrementing by 1 for each subsequent protection
interval.

This allows the application to validate the received reference tags
without ever knowing anything about which start LBA the I/O happened to
come from.

Both DIX and NVMe also allow the hardware to perform the remapping so
the software remapping step can be skipped altogether. Christoph and I
briefly talked about that last week. We currently don't take advantage
of that capability in the NVMe driver.

-- 
Martin K. Petersen