From: Tokunori Ikegami <ikegami.t@gmail.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH v4] nvme: change nvme_ns_has_pi() to nvme_ns_supports_pract()
Date: Thu, 24 Oct 2024 01:33:40 +0900 [thread overview]
Message-ID: <a4d2bbb3-2718-4fda-b225-a2ba66f451cb@gmail.com> (raw)
In-Reply-To: <ZxkSJJm54Gs9exWw@kbusch-mbp>
On 2024/10/24 0:11, Keith Busch wrote:
> The important point for those MS>8 formats is the host *must* provide a
> buffer for the transfer, otherwise you'll get corruption. This means
> those formats are not usable if your kernel didn't set
> CONFIG_BLK_DEV_INTEGRTY, or you have a fabrics transport that doesn't
> support these.
>
> The format where MS == PI size can still work without
> CONFIG_BLK_DEV_INTEGRTY or fabrics support because the the pr-action
> disables the host<->device transfers.
Okay I will do study more later about the block device integrity feature.
> The function, nvme_ns_has_pi(), is specifically looking for the formats
> that don't require the host to provide a metadata buffer. The comment
> above the function says exactly this:
>
> "NVMe ns supports metadata actions by the controller (generate/strip)"
>
> The only time that happens with PRACT is if metadata size equals the PI
> size. Section 2.1.5, Figure 9 says this more succiently.
Now I could understand fully with your advice including the driver
implementation and the section 5.3.2 also checked again.
> It should work fine with any MS>PI size as long as the disk can
> successfully register with blk_integrity, which again, depends on your
> kernel config and transport type. That block layer can handle protection
> information with extra metadata in the same buffer.
Noted this also. Thank you so much for your explanation.
prev parent reply other threads:[~2024-10-23 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 10:08 [PATCH v4] nvme: change nvme_ns_has_pi() to nvme_ns_supports_pract() Tokunori Ikegami
2024-10-23 12:45 ` Christoph Hellwig
2024-10-23 13:14 ` Keith Busch
2024-10-23 13:19 ` Christoph Hellwig
2024-10-23 13:21 ` Keith Busch
2024-10-23 14:44 ` Tokunori Ikegami
2024-10-23 15:11 ` Keith Busch
2024-10-23 16:33 ` Tokunori Ikegami [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=a4d2bbb3-2718-4fda-b225-a2ba66f451cb@gmail.com \
--to=ikegami.t@gmail.com \
--cc=hch@infradead.org \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.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.