| Message ID | 20250227144609.35568-1-gmazyland@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | docs: sysfs-block: Clarify integrity sysfs attributes for non-PI metadata | expand |
| Context | Check | Description |
|---|---|---|
| shin/vmtest-linus-master-PR | success | PR summary |
| shin/vmtest-linus-master-VM_Test-0 | success | Logs for build-kernel |
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.
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
Milan, > thanks for the clarification, should I just update the > patch and add your signed-off line? Feel free to tweak and submit. You can add a Co-developed-by tag, if you wish. > 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? Looks like it, yes. We didn't originally register a profile unless the device was capable. So the "nop" vs. "none" distinction is a recent addition. > - 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) Currently, yes. > - maximal size of usable metadata (currently NVMe metadata_bytes > field). Aside from PI, SCSI doesn't support separate metadata. It does, however, support larger logical block sizes. So 520, 524, 528, etc. And those block sizes may be accompanied by 8 bytes of PI. But the non-PI metadata is considered part of the logical block data and not a separate entity like in NVMe. So until NVMe happened, we didn't have a situation where we could actually have non-PI metadata in a buffer separate from the data. And the block integrity interface still reflects that. > 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). That's fine with me. I do prefer to distinguish between PI and non-PI metadata. Even though they may be sharing a buffer in the NVMe case.
diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index 0cceb2badc83..f67fd46f15b6 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -109,6 +109,8 @@ Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Indicates whether a storage device is capable of storing integrity metadata. Set if the device is T10 PI-capable. + This flag is set if a PI profile is enabled. + It is not set when non-PI metadata are used. 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". What: /sys/block/<disk>/integrity/protection_interval_bytes @@ -142,7 +146,10 @@ Date: June 2008 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Number of bytes of integrity tag space available per - 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. What: /sys/block/<disk>/integrity/write_generate
The /sys/block/<disk>/integrity fields are historically set if PI is enabled. It is not set if some upper layer uses integrity metadata for non-PI format. Document it. Signed-off-by: Milan Broz <gmazyland@gmail.com> --- Documentation/ABI/stable/sysfs-block | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)