kernel 2.6.3 mpt fusion 3.00.03: WWN part of target assignment?

kernel 2.6.3 mpt fusion 3.00.03: WWN part of target assignment?

[Richard F. Rebel]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]


Hello,

I have a LSI logic quad port fibre channel board in two computers on a
small SAN.  The SAN consists of a dual controllered nStor raid, as well
as a dual controller SSD, each port of each device is connected to one
of two QLogic sanbox 5200's.

One of my devices, the 6GB SSD, reports the following WWN by port:

Port 0: 20:00:00:02:34:00:00:9a

Port 2: 20:02:00:02:34:00:00:9a

As you can see, the number are nearly identical except for the 2nd
number which according the the manufacturer equates to the devices
internal port number.

Port 0, is attached to our first switch, port 2, is connected to the
2nd.

The kernel, upon probing the bus, reports that the SSD's target ID is 0
on the first switch, and on the second, it reports target 2.  Why is the
device not being assigned the same target like my other SAN devices.

This is the only device we have that elicits this behavior and it's
bunging up my mappings when I have it connected.  When I disconnect the
device and reboot everything, all of the fiber channel interfaces report
the other SAN devices identically across all paths (desired and
expected).  When I re-connect the SSD to the fabric, in reverse (port 0
on switch 2, port 2 on switch 1) the target's are reversed, but the SSD
still shows up as target 2.

Please forgive my ignorance, but what is responsible for assigning the
target id?  The SSD vendor claims the switch or the host, and most
likely the host is responsible for this.  Is there something I can do to
control this?

Thanks!

-- 
Richard F. Rebel

cat /dev/null > `tty`

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel 2.6.3 mpt fusion 3.00.03: WWN part of target assignment?

[Jeremy Higdon]

On Tue, Dec 14, 2004 at 03:40:23PM -0500, Richard F. Rebel wrote:
> 
> Hello,
> 
> I have a LSI logic quad port fibre channel board in two computers on a
> small SAN.  The SAN consists of a dual controllered nStor raid, as well
> as a dual controller SSD, each port of each device is connected to one
> of two QLogic sanbox 5200's.
> 
> One of my devices, the 6GB SSD, reports the following WWN by port:
> 
> Port 0: 20:00:00:02:34:00:00:9a
> 
> Port 2: 20:02:00:02:34:00:00:9a
> 
> As you can see, the number are nearly identical except for the 2nd
> number which according the the manufacturer equates to the devices
> internal port number.
> 
> Port 0, is attached to our first switch, port 2, is connected to the
> 2nd.
> 
> The kernel, upon probing the bus, reports that the SSD's target ID is 0
> on the first switch, and on the second, it reports target 2.  Why is the
> device not being assigned the same target like my other SAN devices.
> 
> This is the only device we have that elicits this behavior and it's
> bunging up my mappings when I have it connected.  When I disconnect the
> device and reboot everything, all of the fiber channel interfaces report
> the other SAN devices identically across all paths (desired and
> expected).  When I re-connect the SSD to the fabric, in reverse (port 0
> on switch 2, port 2 on switch 1) the target's are reversed, but the SSD
> still shows up as target 2.
> 
> Please forgive my ignorance, but what is responsible for assigning the
> target id?  The SSD vendor claims the switch or the host, and most
> likely the host is responsible for this.  Is there something I can do to
> control this?
> 
> Thanks!
> 
> -- 
> Richard F. Rebel
> 
> cat /dev/null > `tty`

Try using lsiutil to create persistent mappings.  However, relying on
persistent and meaningful target IDs for Fibre SCSI devices is a bad
idea, because they are typically neither.  That's one reason for the
fc_transport API, which you don't have in your old kernel.

jeremy

Re: kernel 2.6.3 mpt fusion 3.00.03: WWN part of target assignment?

[Richard F. Rebel]

[-- Attachment #1: Type: text/plain, Size: 3275 bytes --]


Hello Jeremy,

The helpful folks at LSI informed me of this useful utility.  After a
couple rounds of emails I did make the persistent bindings and an amd64
version for my system.  This did work, although I still don't understand
why the devices were assigned targets differently based on which swich I
see them through.

off-topic...

I still seem to have a performance problem talking to my nStor devices
tho but not others, so I suspect it's not related to the card or driver.

Does anyone else out there have an nStor 4500f system that might like to
share with me their sequential read performance?  I can only get about
45 MBps using good ole dd.  I can saturate the fibre reading from other
devices we have.  I find this odd as the nStor system has two
controllers, each with a co-proc 1GB ram, and it is fully decked out
with 36GB 15k rpm FC drives.  nStor hasn't been all that helpful so far
except to say that the performance should be fine and begin the finger
pointing.  :/

Best,


On Thu, 2004-12-16 at 14:15 -0800, Jeremy Higdon wrote:
> On Tue, Dec 14, 2004 at 03:40:23PM -0500, Richard F. Rebel wrote:
> > 
> > Hello,
> > 
> > I have a LSI logic quad port fibre channel board in two computers on a
> > small SAN.  The SAN consists of a dual controllered nStor raid, as well
> > as a dual controller SSD, each port of each device is connected to one
> > of two QLogic sanbox 5200's.
> > 
> > One of my devices, the 6GB SSD, reports the following WWN by port:
> > 
> > Port 0: 20:00:00:02:34:00:00:9a
> > 
> > Port 2: 20:02:00:02:34:00:00:9a
> > 
> > As you can see, the number are nearly identical except for the 2nd
> > number which according the the manufacturer equates to the devices
> > internal port number.
> > 
> > Port 0, is attached to our first switch, port 2, is connected to the
> > 2nd.
> > 
> > The kernel, upon probing the bus, reports that the SSD's target ID is 0
> > on the first switch, and on the second, it reports target 2.  Why is the
> > device not being assigned the same target like my other SAN devices.
> > 
> > This is the only device we have that elicits this behavior and it's
> > bunging up my mappings when I have it connected.  When I disconnect the
> > device and reboot everything, all of the fiber channel interfaces report
> > the other SAN devices identically across all paths (desired and
> > expected).  When I re-connect the SSD to the fabric, in reverse (port 0
> > on switch 2, port 2 on switch 1) the target's are reversed, but the SSD
> > still shows up as target 2.
> > 
> > Please forgive my ignorance, but what is responsible for assigning the
> > target id?  The SSD vendor claims the switch or the host, and most
> > likely the host is responsible for this.  Is there something I can do to
> > control this?
> > 
> > Thanks!
> > 
> > -- 
> > Richard F. Rebel
> > 
> > cat /dev/null > `tty`
> 
> Try using lsiutil to create persistent mappings.  However, relying on
> persistent and meaningful target IDs for Fibre SCSI devices is a bad
> idea, because they are typically neither.  That's one reason for the
> fc_transport API, which you don't have in your old kernel.
> 
> jeremy
-- 
Richard F. Rebel

cat /dev/null > `tty`

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]