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
