From: Milan Broz <gmazyland@gmail.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-block@vger.kernel.org, axboe@kernel.dk, hch@infradead.org
Subject: Re: [PATCH] docs: sysfs-block: Clarify integrity sysfs attributes for non-PI metadata
Date: Mon, 3 Mar 2025 19:52:48 +0100 [thread overview]
Message-ID: <8aaa0b97-ef9a-4bd8-8f8f-7c6869ff4c26@gmail.com> (raw)
In-Reply-To: <yq1mse2xdlk.fsf@ca-mkp.ca.oracle.com>
Hi Martin,
thanks for the clarification, should I just update the
patch and add your signed-off line?
Anyway, some questions below:
On 3/3/25 6:25 PM, Martin K. Petersen wrote:
>> What: /sys/block/<disk>/integrity/format
>> @@ -117,6 +119,8 @@ Contact: Martin K. Petersen <martin.petersen@oracle.com>
>> Description:
>> Metadata format for integrity capable block device.
>> E.g. T10-DIF-TYPE1-CRC.
>> + If the storage device supports metadata but no PI
>> + is used, this field will contain "nop".
>
> This field describes the type of T10 Protection Information that the
> block device is capable of sending and receiving. If the device does not
> support sending and receiving T10 Protection Information, this field
> contains "nop".
There can be "none" and "nop" here. My understanding was that "none"
means the device does not support any metadata space (no T10 profile possible)
while "nop" is that there is a metadata space but it is not used by
any known T10 profile. Is it correct?
What I need (in userspace):
- a flag that device supports non-PI metadata (is it that "nop" above?)
If not, then there is no way to check for non-PI metadata for non-NVMe
devices (as metadata_bytes is present on NVMe only)
- maximal size of usable metadata (currently NVMe metadata_bytes field).
...
> Wrt. the size of opaque (non-PI) metadata, I think it would good to have
> a dedicated field to describe it.
I think that metadata_bytes would be enough, if supported for all block devices
(note we emulate metadata in dm-integrity, so it should be set there too).
Thanks,
Milan
next prev parent reply other threads:[~2025-03-03 18:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250225092525epcas5p31dd0a19ffdfb39f3f2ce4acd1c6da7ee@epcas5p3.samsung.com>
2025-02-25 9:23 ` sysfs integrity fields use Milan Broz
2025-02-25 10:10 ` Kanchan Joshi
2025-02-25 10:44 ` Kanchan Joshi
2025-02-25 11:03 ` Milan Broz
2025-02-26 10:04 ` Kanchan Joshi
2025-02-25 15:38 ` Christoph Hellwig
2025-02-26 14:02 ` Milan Broz
2025-02-27 14:46 ` [PATCH] docs: sysfs-block: Clarify integrity sysfs attributes for non-PI metadata Milan Broz
2025-03-03 17:25 ` Martin K. Petersen
2025-03-03 18:52 ` Milan Broz [this message]
2025-03-06 2:28 ` Martin K. Petersen
2025-03-18 15:44 ` [PATCH] docs: sysfs-block: Clarify integrity sysfs attributes Milan Broz
2025-03-20 7:04 ` Christoph Hellwig
2025-03-20 11:44 ` Jens Axboe
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=8aaa0b97-ef9a-4bd8-8f8f-7c6869ff4c26@gmail.com \
--to=gmazyland@gmail.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox