Re: [PATCH] docs: sysfs-block: Clarify integrity sysfs attributes for non-PI metadata

["Martin K. Petersen" <martin.petersen@oracle.com>]

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.

-- 
Martin K. Petersen	Oracle Linux Engineering