Not possible to have PI at the end of metadata
irvin cote
irvincoteg at gmail.com
Mon Jul 31 10:22:05 PDT 2023
Hi Ankit,
Thank you for your detailed answer!
So if I got it right, the driver requires PI to be the first bytes of metadata
because the block layer's implementation of t10
only expects the user data to be used for CRC generation.
I guess ithis would be pretty costly to change so as to have the nvme
driver comply
with >=1.0 spec as as you say SCSI also depends on that t10 implementation.
Anyway I had just asked that in case this had not been seen.
Thanks again.
Regards,
Irvin Cote
On Mon, 31 Jul 2023 at 18:04, ankit <ankit1455 at gmail.com> wrote:
>
> Hi Irvin,
>
>
>
> These are the possible scenarios, how PI is handled.
>
>
>
> If PRACT bit is set, and metadata size == pi size, controller inserts / removes PI portion for write / read respectively.
> If PRACT bit is set, and metadata size > pi size
>
> controller overwrites the PI portion of metadata for write before sending it to NVM.
> for read controller does not touch the PI portion of metadata while sending it to the host.
>
> If PRACT bit is not set, then it’s the host responsibility to generate PI for write, and verify for read, irrespective of PI size.
>
>
>
> For PIL (PIP bit of DPS Identify namespace data structure), if its set to 0 then protection information should be transferred at the last bytes of metadata. The guard tag (crc) of PI for this case covers data buffer as well as metadata buffer excluding the PI portion.
>
> If PIP bit is not set the guard tag (crc) only covers data buffer.
>
>
>
> Now coming to nvme-driver working.
>
>
>
> if CONFIG_BLK_DEV_INTEGRITY is set, it registers a integrity profile and block layer provides the metadata buffer. The existing guard tag (crc) calculation is done only on the data buffer, it does not cover metadata buffer excluding the PI portion (you may refer block/t10-pi.c), hence the restriction on PI location as first bytes of metadata. I am not sure, how much effort will be required to modify this (crc on metadata buffer in block/t10-pi.c) as this is used by SCSI driver also.
> If CONFIG_BLK_DEV_INTEGRITY is not set and device is formatted with metadata with PI enabled then the scenarios are
>
> metadata size == pi_size, nvme driver does not need to do anything.
> Metadata size > pi_size, nvme driver sets the capacity to 0 since there is no metadata buffer, which is expected by controller.
>
>
>
> I don’t know how you are trying to use this, but we now have io_uring passthrough (works with nvme character device), kind of bypasses the block layer.
>
>
>
> FIO has an ioengine for that, and I am currently working on adding PI support, and will soon post the patches. It will also cover DIF case (extended LBA), which is not supported with the block device. I hope you will find this interesting for your use-case.
>
>
>
> Regards
>
> Ankit
>
>
>
> Sent from Mail for Windows
>
>
More information about the Linux-nvme
mailing list