Messages in this thread | | | Date | Tue, 28 Nov 2023 12:02:58 -0700 | From | Keith Busch <> | Subject | Re: [RFC v1] nvme: add cse, ds, ms, nsze and nuse to sysfs |
| |
On Tue, Nov 28, 2023 at 02:05:08PM +0100, Christoph Hellwig wrote: > On Mon, Nov 27, 2023 at 09:46:43AM -0700, Keith Busch wrote: > > > > > > Yes. But does it care about the tuple size, or the actual size of the > > > metadata field even if is bigger than the PI tuple? > > > > tuple_size is the same value as metadata size regardless of PI usage. > > See nvme_init_integrity() for how this driver sets it: > > > > integrity.tuple_size = ns->ms; > > Yes, for the case where we actually support integrity in the kernel > for a given device. But if the device has a metadata size larger than > the PI size we still support it, and just let the device strip/insert > the PI.
I'm pretty sure that isn't right. We already support PI regardless of the metadata size as long as the PI field is in the first 8 bytes. Strip/insert doesn't even work if metadata is larger than a PI field. For any metadata case where PI isn't used, the driver requests allocating an empty buffer for the purpose.
> And if nvme-cli wants to report detailed information about > the namespace it probably needs to report the actual metadata size > as the tuple size won't be reported given that we're never initializing > the kernel PI support.
I don't understand. For any namespace with a metadata size, even if the namespace format doesn't have PI support, we still register an "integrity" profile with no-ops to get that unused buffer just so the block layer can access the format. We alyways set the tuple_size to the namespace metadata-size so the kernel buffer is correctly sized.
This all works as long as the metadata is separate (not extended) and kernel has CONFIG_BLK_DEV_INTEGRITY.
| |