[stgt] [PATCH] sg-based backing store

[Alexander Nezhinsky]

>> I applied this patch and it works, but I noticed that the serial number
>> reported by the device (using sg_inq) returned 'beaf11' instead of the real physical serial number.
>>
>> Does it mean that the inquiry command is not transferred to the device and handled internally?
> Yeah, this just uses sg for I/Os. You are talking about passthrough.
>

I guess this serial numbers issue deserves a separate discussion.
Here are two scenarios which indicate that the current scheme of
device identification
handling is not always adequate.

1. There are 2 targets, to which an initiator is connected. Both
automatically generate
"deadbeef" - based serial numbers for their devices. The initiator
gets confused, as it
may decide (seeing deadbee11 twice),  that it works with 2 instances
of the same device
exported by separate targets, acting as "routers".
In this case we lack uniqueness of device id (this can be achieved by adding a
target-specific prefix, any other unique string identifying the machine,
the network card etc.)

2. Within a single target a device is accessible through multiple
paths, each producing
a separate linux device. tgt will generate distinct serial numbers,
like deadbeef11,
deadbeef12 etc., although they all refer to the same device.
Now the initiator is going to have a hard time figuring out what's
going on, trying
to discriminate between different devices and between different paths
to the same device.
In this case we produce uniqueness where uniformity is required.

These problems can be alleviated using the administrative tools, like
scripts which
will gather information about the connectivity, generate and force the
serial numbers etc.
by feeding them thru config files.

But perhaps some smarter choices should be done by stgt alone. I have
no clear-cut
solution for now. Just wanted to hear what you think, maybe it's
considered a non-issue
for example.

In case of sg backing store, though, we do have the true serial
numbers available, once
the INQUIRY command is passed-through. Do you see any problems with that?
And again, as i pointed out in the other mail, this would necessitate
creating a distinct
device-type, based on SBC, just for the sake of changing the INQUIRY
entry in the
dispatch table. Maybe this serial number business (even if other
commands are not)
may be relegated to the BS?

Alexander Nezhinsky
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html