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
