Hi Anuj! > Thanks for the suggestion. I see your point — especially from the NVMe > perspective, where integrity buffer can be larger than just the PI > tuple. > > However, since this ioctl is also intended to work on regular files, > where "metadata" usually refers to inode-level attributes, timestamps, > permissions, etc., I worry that FS_IOC_METADATA_CAP and > fs_metadata_cap might be confusing in the broader filesystem context. > > Using FS_IOC_GETPI_CAP and struct fs_pi_cap seems more narrowly scoped > and avoids that ambiguity. Do you see this differently? Or if you have > a better alternative in mind, I’d be happy to consider it. I agree it's ambiguous. I just find it equally confusing that "PI" is now being used to describe opaque metadata which has nothing to do with PI. When the block layer code was originally implemented I tried to be careful about using the term "integrity metadata" everywhere to distinguish it from "filesystem metadata". It was deliberate not to use T10 terms in the block layer since there were other competing protection formats at the time. So one way to get us out of this naming problem would be to clearly distinguish between for instance "logical block metadata" and "filesystem metadata". An alternative would be to revive the concept of "block tagging". The reason the existing "tag_size" parameter is not called "app_tag_size" is that the "tag" is "filesystem tag". The fact that it was backed by the application tag in the PI case was coincidental. The idea at the time was that filesystems would tag their filesystem blocks with backpointers and additional information about the contents which would be useful in a recovery scenario (i.e. "this is a data block for inode XYZ"). So we could entertain "block tag". Anyway. I'm thinking something along the lines of this: * struct logical_block_metadata_cap - Logical block metadata * @lbmd_flags: Bitmask of logical block metadata capability flags * @lbmd_interval: The amount of data described by each unit of logical block metadata * @lbmd_size: Size in bytes of the logical block metadata associated with each interval * @lbmd_opaque_size: Size in bytes of the opaque block tag associated with each interval * @lbmd_opaque_offset: Offset in bytes of the opaque block tag within the logical block metadata * @lbmd_pi_size: Size in bytes of the T10 PI tuple associated with each interval * @lbmd_pi_offset: Offset in bytes of T10 PI tuple within the logical block metadata * @lbmd_pi_guard_tag_type: T10 PI guard tag type * @lbmd_pi_app_tag_size: Size in bytes of the T10 PI application tag * @lbmd_pi_ref_tag_size: Size in bytes of the T10 PI reference tag * @lbmd_pi_storage_tag_size: Size in bytes of the T10 PI storage tag * @lbmd_rsvd: Reserved for future use That way there's a clear distinction between "all of the metadata", "the non-PI metadata", and "the PI metadata". Also saves the caller from doing size and offset calculations by hand for the non-PI stuff. -- Martin K. Petersen
