[PATCH v4 0/5] block: use integrity interval instead of sector as seed
Christoph Hellwig
hch at lst.de
Tue Jul 14 06:45:58 PDT 2026
On Sun, Jul 12, 2026 at 07:09:01PM -0400, Martin K. Petersen wrote:
>
> Caleb,
>
> > The block integrity layer currently sets the integrity seed (initial
> > reference tag) in units of 512-byte sectors.
>
> ... because that is the fundamental addressing unit in the block layer.
>
> > However, Type 1 and Type 2 ref tags are actually in units of integrity
> > intervals.
>
> They are not in units of anything until they reach their final
> protection envelope.
If that is the assumption we need to clearly specify that somewhere,
and also explain why that is a good idea.
Most users of bip_set_seed seem to assume it is in integrity interval
units, see commits:
e4dc9a4c31fe10d1751c542702afc85be8a5c56a
c6e3f13398123a008cd2ee28f93510b113a32791
3d8b5a22d40435b4a7e58f06ae2cd3506b222898
so we'll need to find out a way to come up with interfaces that
just do the right thing.
>
> > On devices with integrity interval size > 512 bytes, ref tags are
> > seeded incorrectly.
>
> The bip seed is whatever the caller decides it should be. The integrity
> interval size is irrelevant. As is the destination LBA.
>
> > But REQ_OP_ZONE_APPEND operations don't have their ref tags remapped,
> > so the ref tags using units of sectors will be stored to the device.
>
> Then there's a problem with how we handle REQ_OP_ZONE_APPEND. For NVMe,
> the PIREMAP flag should address this issue by remapping the written ref
> tags based on their ultimate destination LBA.
PIREMAP expects the ref tag to be in logical block sized units.
> Fundamentally, you should be able to set the bip seed for any READ or
> WRITE bio to 42, regardless of logical block size, and have it work. If
> it doesn't, then that's a bug.
>
> The fact that the block layer happens to know the start LBA or ZSLBA
> does not mean that callers above the block layer have access to the same
> information. Changing the block layer's integrity handling semantics is
> not the correct approach. Everything above the block layer depends on
> the existing, format-agnostic, semantics.
We have 4 callers above the block layer, and all of them know that the
see is the LBA. For type 1 that is enforced by hardware, and all the
Linux code is basically based around a type 1 model, which is emulate
don type 2 PI and type 3 PI using the available means.
More information about the Linux-nvme
mailing list