RE: iSCSI: problem with LUN discovery

[Nelson Nahum <NNahum@store-age.com>]

John,

The problem is that the signature written by the VxVM is not standard and
only is recognized by the Veritas VxVM.
Due to the fact that the important thing is to identify the media not the
controller (as Veritas does), the best way is to have the serial number
written in the media in a non accessible sector, and loaded by the
controller to one of the Inquiry pages of the LU. In this manner no matter
which channel, WWN, LUN  the specific LUN is presented can be recognized by
every initiator.

Nelson Nahum
CTO
StoreAge Networking Technologies.


-----Original Message-----
From: John Muth [mailto:muth@veritas.com]
Sent: Wednesday, October 04, 2000 4:51 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: problem with LUN discovery


Julo,

FYI. Assuming the initiators are running higher level disk 
management S/W like VxVM (VERITAS Volume Manager), this won't
be a problem. VxVM already deals with device paths moving 
around by doing it's disk identification based on the label, 
not the device path.

John Muth
VERITAS Software

julian_satran@il.ibm.com wrote:
> 
> JP,
> 
> Unless I misunderstood you this is entirely a T10 issue.
> Presenting a different LU map to each initiator as identified by the port
> or the ACCESS-ID is intentional (each initiator can view a different set
of
> LUs)and part
> of the protection mechanisms of SCSI.
> 
> With iSCSI at later stages (when we start handling discovery and
> management)
> the pain of getting to a specific volume might be eased.
> 
> Julo
> 
> Raghavendra Rao <jpr@divyaroot.India.Sun.COM> on 27/09/2000 23:05:22
> 
> Please respond to Raghavendra Rao <jpr@divyaroot.India.Sun.COM>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:
> Subject:  iSCSI: problem with LUN discovery
> 
> Julian,
> 
> Do you agree that following is a problem ? If so, can we fix it ?
> 
>   SAM doesn't prohibit a target device from presenting initiator specific
>   values for LUs. So it is believed that similar values for a LU may not
>   necessarily address the same LU inside a target when accessed from
> different
>   initiators.
> 
>   So the vendor ID page 83 of INQUIRY command is considered to be unique
>   for a LU - There is one caveat to this though, that the page 83 values
>   could optionally be target port specific. Anyway, if the hosts were to
>   use a more persistent values such as page-83 identifier, say after
reboot
>   or after reconfiguration, it first needs to translate this page-83
> identifier
>   into a LUN. This can be done by first issuing a REPORT_LUN command to
>   LUN 0 and issuing an INQUIRY page-83 command to each LU in the list
>   obtained from REPORT_LUN response until a successful match is found.
>   An initiator could cache the mapping for future speedier lookups, but
>   it still has to linearly probe out all LUs to get the page-83 unique
>   identifiers.
> 
>   I hate to do this static probing; This problem can be fixed by either
> 
>      a) mandating that LUN values are persistent and same for all
>         initiators (more unlikely to be accepted)
> 
>   OR
> 
>      b) introducing a new page code for INQUIRY in which the initiator
>         will pass down the page-83 identifier in the parameter list
>         to LUN 0 and the target will respond with the LUN corresponding
>         to this identifier; Of course, this has to go to T10 for approval.
> 
> Thanks.
> -JP