From: Keith Busch <kbusch@kernel.org>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: 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: Wed, 15 Jul 2026 10:01:39 -0600 [thread overview]
Message-ID: <aleu49e4GxG-Z7B6@kbusch-mbp> (raw)
In-Reply-To: <CADUfDZoGheGP6JCwwV=BCBnqxAspJ1n9Aes=UsjtS-DxAMxeEA@mail.gmail.com>
On Wed, Jul 15, 2026 at 08:30:33AM -0700, Caleb Sander Mateos wrote:
> On Tue, Jul 14, 2026 at 6:53 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > For Type 2 this remapping could work, but doing it unconditionally
> > will make all data written using and earlier kernel in a partition
> > unreadable once this changes has been applied.
>
> 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.
next prev parent reply other threads:[~2026-07-15 16:01 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 [this message]
2026-07-16 12:21 ` Christoph Hellwig
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=aleu49e4GxG-Z7B6@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=hch@lst.de \
--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.