The SBP2 application needs two type of logins for
the same device. One to transfer data and another to
inquire the device status. To allow two logins ( one
for data and another for status ), for each physical
instance of device, two LUNs can be defined. One LUN
number is used for data login and another one for
status login.
For example, if the target supports two of similar devices,
then target is configured with 4 LUNS.
0th LUN - For data login on device 1
1st LUN - For status login on device 1
2nd LUN - For data login on device 2
3rd LUN - For status login on device 2.
All of them are defined in one UNIT directory.
If the target supports more than one type of devices. Then for
each device, one unit directory can be defined.
In each unit, based on number of similar devices, we can
have so many LUNs.
For example, if SBP2 target needs to support 2 printer devices
and 3 scanner devices. Assume that printer needs to have two
type of logins and scanner needs to have 4 type of logins.
Then the target system will have two unit directories.
One for printer and another for scanner.
Printer unit directory needs to be defined with 2 * 2 = 4 LUNs.
Scanner unit directory needs to be defined with 3 * 4 = 12 LUNs.
Initiator application and execution agent will have understanding
that
0 and 1st LUNs correspond to first printer device
2nd and 2rd LUNs correspond to second printer device for printer
unit.
For scanner unit,
0,1,2 and 3 are for first scanner device
4,5,6,7 for second scanner device
8,9,10,11 for thrid scanner device.
The above text is example only.
Regards
Srini
Eric Anderson wrote:
> > >
> > > Greg Shue writes:
> > > > The SBP-2 proposal allows this to be modeled as:
> > > > 1 unit with:
> > > > 2 logins to the Print Job logical unit
> > > > N logins to the Printer Status logical unit
> > > > 1 login to the Printer control logical unit
> > > >
> > Eric Anderson:
> > > So at face value I would prefer the first model (above) over
> > > the second.
> > >
> Greg Shue:
> > The big problem with the first model is that you cannot have
> > multiple connections between device status applications and
> > device status services when the applications reside on the same
> > node. This _requires_ that multiplexing be done somewhere in the
> > system.
>
> Hmm, this is an interesting part of SBP-2. No initiator node is
> allowed to have more than one login to the same LUN in a target.
> I believe it was assumed that any initiator that is so complex
> that it might want multiple logins to the same LUN must also be
> so smart that it would be able to multiplex a single login in
> software.
>
> If this problem only comes up in computers (and similar devices)
> then maybe us software folks can do the multiplexing. I didn't
> see details of the Status logical unit in the latest profile,
> but if it has no side-effects, multiplexing access to it might
> not be too hard.
>
> On the other hand, if you forsee devices like printers or scanners
> that might have two or more independent functions that both want
> status from the same target, then it might be more difficult for
> them to share one login, because of the nature of their implemen-
> tations. Do you think this second case is likely, and if so, do
> you think that the difficulty of multiplexing one connection is
> sufficient to warrant using another model of units and logins?
>
> Or should we consider asking SBP-2 to allow multiple logins to one
> LUN from the same initiator? It's not clear to me that the limit
> of one login per LUN per initiator causes any real savings in cost
> or complexity in the target.
>
> --------------------------------------
> Eric Anderson ewa@apple.com
> Apple Computer, Inc. 408-974-8187
> --------------------------------------