From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Sagi Grimberg <sagi@grimberg.me>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] nvme/core: advertise BLK_EXPECTED_REF_TAG_CAPABLE
Date: Thu, 16 Jul 2026 14:21:08 +0200 [thread overview]
Message-ID: <20260716122108.GA30437@lst.de> (raw)
In-Reply-To: <aleu49e4GxG-Z7B6@kbusch-mbp>
On Wed, Jul 15, 2026 at 10:01:39AM -0600, Keith Busch wrote:
> > I mentioned this in the cover letter (and that's why I marked these
> > patches "RFC"). Unless you have a clever idea, it does seem like an
> > insurmountable obstacle here.
>
> We had a similar problem when we enabled PI at the end of the metadata
> rather than just at the beginning. This left machines unbootable after
> upgrading the kernel, so we have a module parameter to turn off support
> for the feature. It's an unpleasant solution as there's no upgrade path
> to ever turn on the feature without a format first.
We could opt into not faking up type 1 PI with a REQ_ or BIP_ flag.
But we'd really need a user that actually wants it first.
prev parent reply other threads:[~2026-07-16 12:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-27 6:19 [RFC PATCH 0/2] Avoid software ref tag remapping for NVMe devices Caleb Sander Mateos
2026-06-27 6:19 ` [RFC PATCH 1/2] blk-integrity: add BLK_EXPECTED_REF_TAG_CAPABLE Caleb Sander Mateos
2026-06-27 6:19 ` [RFC PATCH 2/2] nvme/core: advertise BLK_EXPECTED_REF_TAG_CAPABLE Caleb Sander Mateos
2026-07-14 13:53 ` Christoph Hellwig
2026-07-15 15:30 ` Caleb Sander Mateos
2026-07-15 16:01 ` Keith Busch
2026-07-16 12:21 ` 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=20260716122108.GA30437@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
/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.