On Fri, 2014-01-10 at 11:50 -0800, Andy Grover wrote: > On 01/09/2014 10:21 PM, Nicholas A. Bellinger wrote: > >> What about FORMAT_UNIT emulation? > > > > Would certainly be useful to have.. > > > >> The backstore protection configuration is done at the target side via > >> configfs/targetcli, if you publish DIF support in > >> INQUERY_EVPD/READ_CAPACITY you need to accept protection information format? > > > > Mmmm, these two bits bits are following what scsi_debug is currently > > exposing minus FORMAT_UNIT support..? > > > > MKP..? > > Yes, don't you need FORMAT UNIT because protection information is going > to mean the pi-enabled lun will need to report less blocks? FORMAT_UNIT is simply a mechanism that allows the client to setup the protection information remotely, to complement the per device configfs attribute that does the same thing from the target side. > The ramdisk backstore changes in this series allocate extra space for > PI info, but my understanding was that especially for emulation with > block and fileio backstores, everything needs to go in the same amount > of space. > No, that's only for the interleaved case. > Furthermore, if we want PI info stored along with the blocks, then block > and fileio backstore formats are no longer going to be 1:1 -- requiring > offset calculations, non-aligned read-modify-write, and all that > unpleasantness to be handled? > I'm currently not intending to support interleaved mode into the backend, given that backends not doing emulation expect these to be in seperate SGLs to start. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html