Christoph, >> It fell by the wayside for various reasons. I would love to revive it, >> all it did was skip the remapping step if a flag was set in the profile. > > How much remapping could the hardware do? Would this also work for > remapping a inode-relative ref tag? Do we need to bring it into NVMe? One of the reasons it lost momentum was that NVMe didn't do it for ILBRT/EILBRT. Although of course NVMe doesn't really have an intermediate HBA entity like SCSI. For SCSI it was natural for the HBA to convert between what the host sees and what the disk sees, RAID controllers do it all the time. NVMe didn't pick up that wrinkle. With DIX1.1, you tell the HBA what to expect the first received ref tag to be. That could be the application's file offset or whatever you want. It's just the seed value chosen by the application when the PI was generated. That's passed down the stack along with the PI buffer itself. And then the controller ASIC uses that seed value to program the register for validating the ref tags as it DMAs from host memory. On the outbound side it uses a different value to seed the ref tag generation register when sending the PI on to the drive. I.e. LBA for Type 1. It's really just a matter of the device having separate, programmable registers for ref tag verification and generation. So in terms of NVMe, it's like having ILBRT and EILBRT specified at the same time. The drive should use EILBRT for validating the ref tag in the PI received from host and then use a separate ILBRT as the initial value for the ref tag when writing the PI to media. On reads it works the same way. The controller validates that the ref tag read from media matches the LBA. And then uses the separate register to generate a new ref tag initialized with the seed value requested by the application. Not sure if we'd have room for both an EILBRT and an ILBRT in the same command? Sounds like it would be difficult, especially with the larger ref tags in NVMe. But I'm happy to pursue in NVMe if there is interest. Because it did make a performance difference not having to touch the PI buffer in the I/O path. -- Martin K. Petersen Oracle Linux Engineering
