Re: iSCSI: problem with LUN discovery

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

John Muth,
I agree with your main point that "... initiator specific LUN mapping
presents no problem".  But I think a comment should be made here that a
"Disk Serial Number" may not be the right thing when the Storage Controller
virtualities the Disk Storage.  But to the extent that they present a
Virtual Disk Serial Number (I think that is what is in the VPD at page 83h)
you are correct.

Now at some point I think folks will want a Central Storage Manager to
instruct the Storage Controllers (IBM Sharks, or EMC Symmetrix, etc.) how
to Virtualize the Disks, (that software may come from Veritas, Tivoli, HP,
Compaq, etc.) and that might even include something like  "call this
virtual Disk xyz".  But until that, or something else is done, we will
still have the Storage Controller performing the Virtualizations and naming
the virtual volumes (LUs), and even then placing the "name" in the VPD page
83h.   So  even then, your point about "... initiator specific LUN mapping
presents no problem"  will still remain correct.

.
.
.
John L. Hufferd


John Muth <muth@veritas.com>@ece.cmu.edu on 10/04/2000 10:39:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: problem with LUN discovery



Nelson,

I don't disagree, disk serial numbers are a good thing. I was
simply trying to point out (perhaps badly) that initiator specific
LUN mapping presents no problem to the initiator side since nobody
in their right mind uses the path to determine the identity of
a disk.

Now, if we could only convince all of the disk manufacturers
in the world (both real and virtual) to give us unique serial numbers
(we've seen drive models were every unit returned the same constant
serial number. and don't get me started about arrays....)

John Muth
VERITAS Software

Nelson Nahum wrote:
>
> 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