Sun Storage 6580 Array
 
Sun Storage 2540-M2 Array
 
Sun Storage 6780 Array
 
Sun Storage SAN Foundation Software
 
Sun Storage 2540 Array
 
Sun Storage 6140 Array
 
Sun Storage 6180 Array
 
Sun Storage Traffic Manager Software
 
Sun Storage 6540 Array
 

PLA-Support>Sun Systems>DISK>Arrays>SN-DK: FLX300_65xx_6780
 

In this Document

Purpose

Details

Applies to:

Purpose

The purpose of this document is to provide recommendations for fibre channel timeout values on Solaris SPARC or x86 only before performing a controller firmware upgrade on Sun Storage 6000, 2500 or 2500-M2 arrays.

Details

A Sun Storage 6000, 2500 or 2500-M2 controller firmware upgrade goes through the following steps:

1. Sun Storage Common Array Manager (CAM) sends the new firmware file (using chunks) to controller A.
2. Controller A verifies the checksum for each chunk and if it is valid, it sends a copy to controller B.
3. Once the transfer completes, CAM requests controller A to activate the new firmware on it.
4. At this time controller A reboots, which takes between 20-40 seconds.
5. After controller A completes its reboot, controller B is automatically rebooted and takes also between 20-40 seconds.

When controller A reboots, the fibre channel targets (controller host ports) disappear. Sun StorEdge Traffic Manager (STMS aka MPxIO) is designed to offline the path 20 seconds after the targets disappear, which means that at this time there is an STMS failover to the controller B path. Then about 20 seconds later when controller A comes back online, the targets reappear. This means that STMS can failback the volumes; however this process may take some time depending on the workload on a production environment. Despite this controller B is automatically rebooted to activate its firmware, and when the targets from controller B disappear, STMS may not have completed the failback of all the volumes. As a result, the host applications may temporarily lose access to the volumes, and this may lead to "transport rejected fatal error " events like the following:

 
In order to prevent these transport errors, the recommendation is to temporarily increase the timeout variable which offlines the path and which is called fcp_offline_delay. By default this variable is set to 20 seconds. The recommendation before performing a controller firmware upgrade is to increase this value to 50 seconds. Then it can be changed back to 20 seconds after the controller firmware upgrade activity completes.

Procedure to change the "fcp_offline_delay" value to 50 seconds:

1. Execute the following command to set the value to 50:
   
   
   # echo fcp_offline_delay/W 0t50 | mdb -kw
    
   
   Example:
   
   # echo fcp_offline_delay/W 0t50 | mdb -kw
   fcp_offline_delay:              0x14            =       0x32
   
   
   
2. Confirm the value with the following command:
   
   
   # echo fcp_offline_delay/D | mdb -k
    
   
   Example:
   
   # echo fcp_offline_delay/D | mdb -k
   fcp_offline_delay:
   fcp_offline_delay:              50
    
   
   

Procedure to change the "fcp_offline_delay" value back to 20 seconds:

1. Execute the following command to set the value to 20:
   
   
   # echo fcp_offline_delay/W 0t20 | mdb -kw
    
   
   Example:
   
   # echo fcp_offline_delay/W 0t20 | mdb -kw
   fcp_offline_delay:              0x32            =       0x14
   
   
   
2. Confirm the value with the following command:
   
   
   # echo fcp_offline_delay/D | mdb -k
    
   
   Example:
   
   # echo fcp_offline_delay/D | mdb -k
   fcp_offline_delay:
   fcp_offline_delay:              20
    

This solution has no attachment