On Fri, Jun 6, 2025 at 7:37 AM Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > > Hi Anuj! > > > A new structure struct fs_pi_cap is introduced, which contains the > > following fields: > > Maybe fs_metadata_cap and then fmd_ as prefix in the struct? > > > > + case FS_IOC_GETPICAP: > > + return blk_get_pi_cap(bdev, argp); > > FS_IOC_METADATA_CAP? > Hi Martin, 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. Thanks, Anuj Gupta
