Re: [PATCH v4 0/5] block: use integrity interval instead of sector as seed
Christoph Hellwig <[email protected]> Tue, 14 Jul 2026 15:45:58 +0200
| Newsgroups | org.kernel.vger.target-devel,org.infradead.lists.linux-nvme,org.kernel.vger.linux-block,org.kernel.vger.linux-kernel,org.kernel.vger.linux-scsi |
|---|---|
| Message-ID | <[email protected]> |
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.