On Wed, 2014-04-02 at 14:43 +0300, sagi grimberg wrote: > On 4/1/2014 8:45 PM, Nicholas A. Bellinger wrote: > > 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. > > Not sure I understood your intention here. > Do you mean that the backstore doesn't support T10-PI, the transport > support T10-PI and target publish to fabric that it support T10-PI? > This will lead to the DIN_INSERT/DOUT_STRIP you are referring to right? Correct. > Is there any value to publish the fabric PI support if your backing > device doesn't support it? So yes, I think there is value is allowing a transport to publish PI support for a device, even when the backend does not support it. In terms of the possibilities for data corruption, moving payloads between physical hosts would certainly have a higher potential given the complexity and number of overall components involved in the transaction. If all unprotected devices should report PI (by default) when the transport supports it is a separate question.. ;) > > The opposite case (backstore support, transport no support) it makes > sense to NOT publish support and do half-way protection in SW > (the backstore is formatted with PI). > Correct. --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
