Thank you for the reply, and all the work you've done to make sas
support a reality. I do appreciate the need.
"James C. McPherson" <[EMAIL PROTECTED]> writes:
>> I haven't found a very good way to map luns to drive names. This looks
>> like it's buried in the prtconf -v output, but by wwn not lun. Do other
>> people have a solution here?
>
> What benefit do you believe this will provide to you?
I often have many similar volumes on my disk shelf, and telling which
disk volume does with what solaris device is hard. This may be less of
an issue when I'm in production, but I still feel like I'll want to know
which storage device is what -- when my raid says it's degraded volume1
I'd like to know which drive that corresponds to. I'm under the
impression that this is pretty well supported under FC, though that
might require the vendor specific tools.
>> I don't see a way to configure and unconfigure devices. I think this
>> would normally be part of cfgadm, but cfgadm doesn't support multipath
>> sas. Is there something short of rebooting that will handle this? I'm not
>> really sure what this means for disk failures and zfs, but other forum
>> posts do not leave me hopeful.
>
> Your targets and luns should just show up automatically. We did
> a lot of work to make sure that this happens with as small a
> requirement for user interaction as possible. If it's not working,
> please let me know exactly what happened - my group delivered that
> support and we're interested in any failures.
As I wasn't testing for failure explicitly, it's hard for me to quantify
what I've seen. I believe that creating new luns usually showed up,
though I think there was a single exception. Destroying luns makes
mpathadm break, though I think the system itself remains stable. I think
I've had mixed results changing a lun.
>> Generally speaking solaris support for multipath feels very immature,
>> there isn't the same level of tools that fibre channel has. Are other
>> people using it, or is everything just waiting for maturity?
>
> So apart from mpathadm, what do you think is missing? Is it just
> utility availability which leads you to that impression, or are
> there other things?
To clarify, I'm referring only to sas here. It's a combination of a
several things.
* Support has been evolving very rapidly, so my experience from 10
months ago certainly colors this.
* mpathadm's crashing on lun removal feels weird. It may not be fatal,
but it totally horks some of my use. (might be bug 6681713 or 6559281)
* cfgadm doesn't support MPxIO sas devices (bug 6569367). Maybe it's
no longer necessary, but a lot of best practice literature points to
it.
* documentation/best practice feels thin. I don't see a lot of people
using this.
All that said, I'm glad to see you as actively engaged about it.
seph
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
