On Tue, Feb 25, 2025 at 10:23:49AM +0100, Milan Broz wrote: > Hi, > > I tried to add some support for using devices with PI/DIF metadata > For an NVMe drive, reformatted to 4096 + 64 profile, I see this:
Based on everything below you have no formatted it with PI and you also don't plan to use PI, just plain non-integrity metadata. > > - /sys/block/<disk>/integrity/device_is_integrity_capable > Contains 0 (?) > According to docs, this field > "Indicates whether a storage device is capable of storing integrity metadata. > Set if the device is T10 PI-capable." this is only 1 if protection information is enabled, and 0 for non-PI metadata. > - /sys/block/<disk>/integrity/tag_size > Contains 0 (?) > According to docs, this is "Number of bytes of integrity tag space > available per 512 bytes of data." > (I think 512 bytes is incorrect; it should be sector size, or perhaps > value in protection_interval_bytes, though.) Yes, it should be an integrity interval. Which for all current drivers is the LBA size. And the tag_size is the size of the PI metadata, so 0 is expected. > Then we have new (undocumented) value for NVMe in > - /sys/block/<nvme>/integrity/metadata_bytes > This contains the correct 64. Yes, this contains the full size of the metadata. And besides documenting it we should probably also lift it to the block layer. > Anyway, when I try to use it (for authentication tags in dm-crypt), it works. > > Should tag_size and device_is_integrity_capable be set even for the "nop" > format? > Is it a bug or a feature? :-) It is expected. The only issue is that the block support for metadata is called integrity all over because it was initially added for PI only and then extended for non-PI metadata, which makes things a little confusing. > If not, what is the correct way to read per-sector metadata size (not only > for NVMe > as metadata_bytes is not available for other block devices)? Right now the nvme specific attribute is the only way.
