Sun Storage 6320 System
 
Sun Storage T3 Array
 
Sun Storage T3+ Array
 
Sun Storage 6120 Array
 

GCS>Sun Microsystems>Sun Alert>Criteria Category>Availability
 
GCS>Sun Microsystems>Sun Alert>Release Phase>Resolved
 

Sun StorEdge T3+, Sun StorEdge 6120 or 6320 Arrays with firmware 3.1.2 or earlier may experience performance degradation if the LUN permission of volume slices are modified or the HBA port World-Wide-Number (wwn) is improperly changed.

This issue can occur on the following platforms:

SPARC Platform

• Sun StorEdge 6120 and 6320 Array with firmware 3.1.2 or earlier and without firmware 3.1.3 (as delivered with patch 115179-06)
• Sun StorEdge T3+ Array with firmware 3.1.2 or earlier and without firmware 3.1.3 (as delivered with patch 115180-04)

Should the described issue occur, the storage array may experience noticeable performance degradation.

There is no workaround for this issue. Please see the "Resolution" section below.

This issue is addressed on the following platforms:

SPARC Platform

• Sun StorEdge 6120 and 6320 Array with firmware 3.1.3 (as delivered with patch 115179-06) or later
• Sun StorEdge T3+ Array with firmware 3.1.3 (as delivered with patch 115180-04) or later

References

From Engineering:

The following steps will cause "lmk_data.lmk_filter.accessibility[elun]" internal flag to be set to "ACC_PARTIAL_DEF_YES" for the slice (i.e. for the slice whose permission is being modified). This flag will not change back to ACC_ALL even if the configuration is changed back to the initial setting. In the following example, if we assign a read/write permission to lun 0 for host PWWN 210000e08b08ab10, then changed the permission to "none" or "read only" (which causes the "ACC_PARTIAL_DEF_YES" flag to be set), then changed it back to "read/write", the flag is not set back to ACC_ALL:

    <hostname>:/:<1> lun perm lun 0 rw wwn 210000e08b08ab10

     <hostname>:/:<2> lun perm list

     <hostname>:/:<3> lun perm 0 <ro|none> wwn 210000e08b08ab10

     <hostname>:/:<4> lun perm lun 0 rw wwn 210000e08b08ab10

     <hostname>:/:<5> lun perm list

The above condition by itself does not cause the performance degradation, as long as the HBA's PWWN does not change. If a different HBA is connected to the array and the PWWN of the new HBA is not shown in the output of "lun wwn list" then the performance degradation will be observed. To fix this condition, execute the following:

    <hostname>:/:<1> lun perm all_lun rw all_wwn

     <hostname>:/:<2> wwn rm all

The above will insure the flag is properly set and any possible stale WWNs cleared. Obviously, you need to set the permissions again after executing the above commands.

Notes: Should the described issue occur, the storage array may experience noticeable performance degradation, possibly on the order of 30% slower (depending on the environment). The output after the last step (step <5>) is the same as the output of step 1 when the accessibility flag was set to ACC_ALL. This condition by itself does not cause the performance degradation as long as the HBA's PWWN does not change. If a different HBA is connected to the array after step <4>, and the PWWN of the new HBA is not shown in the output of 'lun wwn list', or the PWWN is removed (thru the 'lun wwn rm <all|wwn #>' command), then the performance is impacted. This condition can occur if the array's slice permission is modified (using the above steps) during testing/integration before shipping the box to a customer. The customer will then configure the lun permission using, for example, the "lun perm lun # <rw|ro|none> <wwn #>" command without knowing the existing state of the lun permission.

The last step and the first step are not the same. But the net effect from the 1st step to the last setp would be eqivalent. i.e. all the host HBAs can access any of the luns in the system.

The issue here is that since the global flag of this LUN remains the same as "ACC_PARTIAL_DEF_YES" after the last step which can cause unnecessary delay for each coming I/O command to go through the port login code path. This process results in performance impact.

The ACC_PARTIAL_DEF_YES is an internal flag that's not visible to the user, and there are no commands that allow the user to examine the register containing the state of Access Definition setting.

References

This solution has no attachment