On 12/18/2013 01:20 AM, Hannes Reinecke wrote:
On 12/17/2013 09:01 PM, Nicholas A. Bellinger wrote:
On Tue, 2013-12-17 at 11:50 -0800, Nicholas A. Bellinger wrote:
On Tue, 2013-12-17 at 09:18 +0100, Hannes Reinecke wrote:
We should be including a descriptor referring to the target device
to allow identification of different TCM instances.
Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
---
drivers/target/target_core_spc.c | 43 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
One issue with this patch. The local buffer in spc_emulate_inquiry is
currently hardcoded to SE_INQUIRY_BUF=512, so two large scsi name
designators could overflow here..
So for the largest case with EVPD=0x83, this would be:
4 bytes for header +
20 bytes for NAA IEEE Registered Extended Assigned designator +
56 bytes for T10 Vendor Identifier +
8 bytes for Relative target port +
8 bytes for Target port group +
8 bytes for Logical unit group +
256 bytes for SCSI name (target port) +
256 bytes for SCSI name (target device) == 616 bytes.
So for good measure, bumping up SE_INQUIRY_BUF to 1024.
Mmmm, looking at this again, is reporting back two SCSI names in
EVPD=0x83 with different associations (one for target port, and one for
target device) really necessary..?
Doesn't the existing target port association report back the same
information..?
No.
'Target port' is the identification for the port handling the
request, which is contained within a target device.
The reason why we need this is that we want to identify the scope of
the Target port group number.
Target port group numbers are relative to the encompassing target
device, so when we're having _several_ target devices they might
well provide us with identical target port group numbers.
For explicit ALUA each target port group within a target device can
be thought of a 'scheduling domain', ie if I sent STPG to one of the
devices in that domain there is a _high_ likelihood that _every_
device within that scheduling domain will be affected.
So I can be slightly smarter here and just send one STPG and then
wait for the resulting states on all affected devices.
If I don't have this information I am required to send STPG to each
and every device, thereby flooding the target controller with STPGs
for the same target port group.
So yes, we should be furnishing both.
In addition it's the only sane way of identifying the array :-)
Hi, fbfe858 only bumps INQUIRY_BUF to 768 although the comment says
1024, is this expected and ok?
Regards -- Andy
--
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
