Hi Anuj!
Thanks for working on this!
> 4. tuple_size: size (in bytes) of the protection information tuple.
> 6. pi_offset: offset of protection info within the tuple.
I find this a little confusing. The T10 PI tuple is <guard, app, ref>.
I acknowledge things currently are a bit muddy in the block layer since
tuple_size has been transmogrified to hold the NVMe metadata size.
But for a new user-visible interface I think we should make the
terminology clear. The tuple is the PI and not the rest of the metadata.
So I think you'd want:
4. metadata_size: size (in bytes) of the metadata associated with each interval.
6. pi_offset: offset of protection information tuple within the metadata.
> +#define FILE_PI_CAP_INTEGRITY (1 << 0)
> +#define FILE_PI_CAP_REFTAG (1 << 1)
You'll also need to have corresponding uapi defines for:
enum blk_integrity_checksum {
BLK_INTEGRITY_CSUM_NONE = 0,
BLK_INTEGRITY_CSUM_IP = 1,
BLK_INTEGRITY_CSUM_CRC = 2,
BLK_INTEGRITY_CSUM_CRC64 = 3,
} __packed ;
> +
> +/*
> + * struct fs_pi_cap - protection information(PI) capability descriptor
> + * @flags: Bitmask of capability flags
> + * @interval: Number of bytes of data per PI tuple
> + * @csum_type: Checksum type
> + * @tuple_size: Size in bytes of the PI tuple
> + * @tag_size: Size of the tag area within the tuple
> + * @pi_offset: Offset in bytes of the PI metadata within the tuple
> + * @rsvd: Reserved for future use
See above for distinction between metadata and PI tuple. The question is
whether we need to report the size of those two separately (both in
kernel and in this structure). Otherwise how do we know how big the PI
tuple is? Or do we infer that from the csum_type?
Also, for the extended NVMe PI types we'd probably need to know the size
of the ref tag and the storage tag.
--
Martin K. Petersen
