Hi Frank,
Frank Cusack wrote:
On January 20, 2007 6:08:07 PM -0800 Richard Elling
Frank Cusack wrote:
On January 19, 2007 5:59:13 PM -0800 "David J. Orman"
card that supports SAS would be *ideal*,
Except that SAS support on Solaris is not very good.
One major problem is they treat it like scsi when instead they should
treat it like FC (or native SATA).
uhmm... SAS is serial attached SCSI, why wouldn't we treat it like SCSI?
On January 21, 2007 8:17:10 PM +1100 "James C. McPherson"
Uh ... you do know that the second "S" in SAS stands for
"serial-attached SCSI", right?
Uh ... you do know that the SCSI part of SAS refers to the command
set, right? And not the physical topology and associated things.
(Please forgive any terminology errors, you know what I mean.)
That seems like saying, "Uh ... you do know that there is no SCSI in FC,
right?" (Yet FC is still SCSI.)
Sorry, I should have been more specific there. I was responding
on your "(or native SATA)" comment.
Would you please expand upon this, because I'm really interested
in what your thoughts are..... since I work on Sun's SAS driver :)
SAS is limited, by the Solaris driver, to 16 devices.
Correct.
Not even that,
it's limited to devices with SCSI id's 0-15, so if you have 16 drives
and they start at id 10, well you only get access to 6 of them.
Why would you start your numbering at 10?
But SAS doesn't even really have scsi target id's. It has WWN-like
identifiers. I guess HBAs do some kind of mapping but it's not
reliable and can change, and inspecting or hardcoding device->id
mappings requires changing settings in the card's BIOS/OF.
SAS has WWNs because that is what the standard requires. SAS hba
implementors are free to map WWNs to relatively user-friendly
identifiers, which is what the LSI SAS1064/SAS1064/E chips do.
Also, the HBA may renumber devices. That can be a big problem.
Agreed. No argument there!
It would be better to use the SASAddress the way the fibre channel
drivers use the WWN. Drives could still be mapped to scsi id's, but
it should be done by the Solaris driver, not the HBA. And when
multipathing the names should change like with FC.
That too is my preference. We're currently working on multipathing
with SAS.
That's one thing. The other is unreliability with many devices
attached. I've talked to others that have had this problem as well.
I offered to send my controller(s) and JBOD to Sun for testing, through
the support channel (I had a bug open on this for awhile), but they
didn't want it. I think it came down to the classic "we don't
sell that hardware" problem. The onboard SAS controllers (x4100, v215
etc) work fine due to the limited topology. I wonder how you fix
(hardcode) the scsi id's with those. Because you're not doing it
with a PCI card.
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 :)
best regards,
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
