From: Christoph Hellwig <hch@lst.de>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
Anuj Gupta <anuj20.g@samsung.com>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] block: use integrity interval instead of sector as seed
Date: Tue, 14 Jul 2026 15:45:58 +0200 [thread overview]
Message-ID: <20260714134558.GA714@lst.de> (raw)
In-Reply-To: <yq1cxwrdgmx.fsf@ca-mkp.ca.oracle.com>
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.
prev parent reply other threads:[~2026-07-14 13:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-27 5:42 [PATCH v4 0/5] block: use integrity interval instead of sector as seed Caleb Sander Mateos
2026-06-27 5:42 ` [PATCH v4 1/5] " Caleb Sander Mateos
2026-07-01 19:56 ` Caleb Sander Mateos
2026-07-02 23:41 ` Martin K. Petersen
2026-06-27 5:42 ` [PATCH v4 2/5] blk-integrity: take u64 in bio_integrity_intervals() Caleb Sander Mateos
2026-06-27 5:42 ` [PATCH v4 3/5] bio-integrity-fs: use integrity interval instead of sector as seed Caleb Sander Mateos
2026-06-27 5:55 ` sashiko-bot
2026-06-27 6:44 ` Caleb Sander Mateos
2026-06-27 5:42 ` [PATCH v4 4/5] t10-pi: use bio_integrity_intervals() helper Caleb Sander Mateos
2026-06-27 5:42 ` [PATCH v4 5/5] blk-integrity: avoid sector_t in bip_{get,set}_seed() Caleb Sander Mateos
2026-07-12 23:09 ` [PATCH v4 0/5] block: use integrity interval instead of sector as seed Martin K. Petersen
2026-07-13 15:50 ` Caleb Sander Mateos
2026-07-14 13:45 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260714134558.GA714@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.