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.
So trying to understand how this will come to use.
Target will publish the fabric T10-PI support based only on the
transport configuration (not accounting the backing devices configuration).
Then upon each cmd the target will look on {backstore configuration,
PROTECT bit, transport configuration} - then will decide on protection
operation (STRIP/INSERT/PASS).
Looks right?
Sagi.
--
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
