From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Milan Broz <gmazyland@gmail.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, 03 Mar 2025 12:25:58 -0500 [thread overview]
Message-ID: <yq1mse2xdlk.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <20250227144609.35568-1-gmazyland@gmail.com> (Milan Broz's message of "Thu, 27 Feb 2025 15:46:09 +0100")
Milan,
> + This flag is set if a PI profile is enabled.
> + It is not set when non-PI metadata are used.
This flag is set to 1 if the storage media is formatted with T10
Protection Information. If the storage media is not formatted with T10
Protection Information, this flag is set to 0.
> 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".
> - 512 bytes of data.
> + protection_interval_bytes, which is typically
> + the device's logical block size.
> + If the storage device supports metadata but no PI
> + is used, this field will contain 0.
This field describes the size of the application tag if the storage
device is formatted with T10 Protection Information and permits use of
the application tag. tag_size is reported in bytes and indicates the
space available for adding an opaque tag to each block
(protection_interval_bytes). If the device does not support T10
Protection Information or the device uses the application tag space
internally, this field is set to 0.
Wrt. the size of opaque (non-PI) metadata, I think it would good to have
a dedicated field to describe it.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2025-03-03 17:26 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 [this message]
2025-03-03 18:52 ` Milan Broz
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=yq1mse2xdlk.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=axboe@kernel.dk \
--cc=gmazyland@gmail.com \
--cc=hch@infradead.org \
--cc=linux-block@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox