Hi Martin,
I can not say if this is a common use case as I don't have field data to
backup.
I believe that this is a show-stopper for us but ultimately, it's up to
the P-team to decide
as you indicated.
As for MPxIO enabling by default on SPARC, I remember it was implemented
in early snv builds (around b49 or so) but then reverted back to non-MPxIO
mode due to problem at the time related to MPxIO being enabled by default.
Son
On 04/12/12 20:48, Martin Widjaja wrote:
Hi Son,
I am just wondering if this is a common use case, and from our last
email exchange it was not clear anyone has the data, but I guess you
are saying this is quite common. Is that right?
To clarify my statement below: Eventually the stopper status is a
P-team call, but I'd really like to get the Rel Mgmt state of this bug
to be "non-stopper" if the use case is not common. I remember Larry's
email to George 2 months ago asking P-team to consider this as a
stopper, but so far no movement. The bug just cannot be sitting in
potential-stopper state for a few months and yet be really important,
can it? I am really asking about the procedure here.
That said, Jesse has been looking into getting a fix for this bug in
his spare time (credit also goes to him for clarifying every little
detail in this case). He ran into several issues while trying to get a
fix working, but nevertheless a fix is in the works. Additionally,
because MPxIO enablement would allow this to work fine from users
perspective, he's also been working with the kernel IO team to see if
it is feasible to re-enable MPxIO which will avoid exposing this
problem in the first place.
Martin
On 4/12/2012 8:36 AM, Son Nguyen wrote:
Hi All,
I disagree with dropping the stopper status for CR 7079889 due to the
following
reasons.
1) Any customers with an external FC device can not use it to install
the latest S11U1
and there is currently no work-around that we are aware of.
2) T5 and M4 product groups also consider this to be a product show
stopper.
Please refer to Larry Wiebe's email on 2/17/2012 that Martin and Drew
were copied on
for details.
Thanks,
Son
On 4/12/2012 5:56 AM, Jesse Butler wrote:
On Apr 11, 2012, at 10:28 PM, Martin Widjaja wrote:
Jesse - Thanks for taking this up.
One question: any additional unit test or test case we need to
introduce to ensure this works fine? If it's a test case, might it
be worth mentioning it to QE so they can include this in their list?
I see Drew replied to this.
Other than that, LGTM!
Thanks!
BTW, for the other bug, 7079889, I was going to remove the
potential stopper status today but didn't get around to it. I will
do this tomorrow and keep you and Son in the loop.
I'm fine with dropping the stopper status if the SAN test team are.
Last I knew, they were not. From their perspective, it's definitely
a stopper, as no SPARC system can use an MP LUN for its
installation. Note they are also fine with the more complete
solution of enabling MPxIO by default in Solaris on SPARC, but that
has yet to be fully vetted, let alone decided upon.
thanks
Jesse
Thanks,
Martin
On 4/11/2012 7:02 PM, Drew Fisher wrote:
LGTM!
Thanks for working on the fix to this!
-Drew
On 4/11/12 7:58 PM, Jesse Butler wrote:
Could I get a review for:
7150578 install discovery ignores device path lun numbers
This CR is a small piece of the overall multipath target
selection issue that the discovery code has. When we encounter
multipath targets with MPxIO disabled, as is the default on
SPARC, everything kind of falls apart. This is being worked
separately.
During that work, this bug was discovered. For each drive we
discover, we retrieve a WWN. If the WWN name is found, we use it.
We throw out subsequent drives with the same WWN.
This is a problem in a few scenarios, most commonly when a RAID
array is used. Most RAID arrays use the WWN of the HBA and a LUN
number to identify a LUN. So, the current code will only discover
one LUN per WWN, throwing away all the other LUNs using the same
WWN. This could be the entire array on some configurations.
Further, the ones that are put on the list are missing their LUN
number.
This changeset tacks the LUN number onto the end of the WWN
string if it's in use, thus getting around the bad duplication
avoidance, and setting a full WWN+LUN descriptor for each Disk
object.
https://cr.opensolaris.org/action/browse/caiman/jesseb/7150578/webrev/
Thanks
Jesse
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
