On Tue, 2014-04-01 at 20:27 +0300, sagi grimberg wrote: > On 4/1/2014 8:09 PM, Martin K. Petersen wrote: > >>>>>> "Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes: > > Sagi> I originally wrote the code to support that. But it got left > > Sagi> behind since I figured it is not an interesting use-case. If your > > Sagi> beckend doesn't support T10-PI why should the target publish it > > Sagi> support it and ask the device to strip/insert it? I suppose it is > > Sagi> to allow the initiator to protect half-way, but I don't know how > > Sagi> interesting it is if the data is not stored with protection... > > > > That depends what you do on the backend. There are several devices out > > there that expose PI to the host but use a different protection scheme > > internally. And then synthesize PI on the host-facing side. Some even do > > T10 PI to an internal protection scheme and then back to T10 PI when > > talking to the disk drives in the back end. > > > > Hey Martin, > > I understand, but even for internal different T10-PI schemes, is > stripping protection from incoming data > at the fabric level (and then do whatever with it in the backend level) > the right thing to do here? > I mean we basically lose protection across the PCI with this scheme > aren't we? > The WRITE_STRIP + READ_INSERT case would be still be useful for IBLOCK backends that don't support real hw PI, so that at least the protection can be in place for data movement between physical machines. Also, I think the amount of changes required to support this type of configuration in target-core are quite small. --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
