Frank Cusack wrote:
On January 23, 2007 8:53:30 AM +1100 "James C. McPherson"
...
Why would you start your numbering at 10?
Because you don't have a choice. It is up to the HBA and getting it
to do the right thing (ie, what you want) isn't always easy. IIRC,
the LSI Logic HBA(s) I had would automatically remember SASAddress to
SCSI ID mappings. So if you had attached 16 drives, removed one
and replaced it with a different one (even in a JBOD, ie it would
be attached to the same PHY), it would be id 16, because the first 16
scsi id's (0-15) were already accounted for. And then the new drive,
lets call it a replacement for a failed drive, would be unaccessible
under Solaris.
Oh heck. That sounds like one helluva broken way of doing things.
Why it would ever start at something other than 0, I'm not sure. I
also kind of remember that scsi.conf had some setting to map the HBA
to target 7 (which doesn't apply to SAS! yet the reference there was
specifically for LSI 1068. again IIRC). I think that I was seeing
that drives started at 8 because of this initialization, and that
removing it allowed the drives to start at 0 -- once I reset the HBA
BIOS to forget the mappings it had already made.
/me groans ... more brokenness. I'll pass this onto some others in
our team who've been working on a similar issue.
...
With a physically limited topology numbering isn't an issue because
of the way that the ports are connected to the onboard devices. It's
external devices (requiring a plugin hba) where it's potentially a
problem. Of course, to fully exploit that situation you'd need to
have 64K addressable targets attached to a single controller, and
that hasn't happened yet. So we do have a window of opportunity :)
I believe SAS supports a maximum of 128 devices per controller, including
multipliers.
Not quite correct - each expander device can have 128 connections,
up to a max of 16256 devices in a single SAS domain. My figure of
64K addressable targets makes an assumption about the number of
SAS domains that a controller can have :)
Even so, we've still got that window.
cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
