Sun Storage 3510 FC Array
 
Sun Storage 3310 Array
 
Sun Storage 3511 SATA Array
 

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

Using sccli(1M) to change the cache optimization mode (sequential vs random) without first deleting all existing logical drives and then performing a reset of the array can affect filesystem availability and data integrity.

This issue can occur on the following platforms:

• Sun StorEdge 3310 (SCSI) Array without sccli 1.6.2
• Sun StorEdge 3510 FC Array without sccli 1.6.2
• Sun StorEdge 3511 FC Array (SATA) without sccli 1.6.2

The RAID controller operates with the same stripe size for all logical drives and the optimization mode is dependent on any existing logical drives configured. Should the operator change the optimization mode (i.e., "sequential" to "random"), without deleting all existing logical drives and resetting the array, the operating mode is still at "sequential" even though the optimization mode displays as "random." Any subsequent logical drives created will be labeled as "random" mode, even though the active operating mode is "sequential," and any data written to the newly created logical drives will be written using "sequential" mode stripe size instead.

The next time the controller(s) is reset or power cycled, the operating mode now changes to "random," as determined by the metadata on the existing logical drive(s), and a data mismatch will occur. Since the data was initially written as "sequential" and now the operating mode is "random," the data presented back to the host will appear to be out of sequence and corrupted as the stripe size and access pattern have been changed.

Data presented to host applications will appear to be corrupted and out of sequence. Volume management applications may not be able to import disk groups and fsck(1M) will be unsuccessful.

The proper procedures to change optimization mode without running into a data mismatch are:

1. Back up data, if needed for later use
2. Delete all existing logical drives
3. Change optimization mode
4. Reset or power cycle the array unit
5. Create new logical drives

This issue is resolved on the following platforms:

• Sun StorEdge 3310 (SCSI) Array with sccli 1.6.2 or later
• Sun StorEdge 3510 FC Array with sccli 1.6.2 or later
• Sun StorEdge 3511 FC Array (SATA) with sccli 1.6.2 or later

12-Oct-2005:

• Updated Contributing Factors and Resolution sections, re-release as Resolved

From engineering:

Should a data mismatch occur specifically due to incorrectly changing optimization modes, please consult Sun for assistance as the data might be recovered through a series of complex processes performed only by highly trained personnel.

Upcoming CLI release 1.6.2 will prevent the user from changing the cache optimization mode while there is an existing LD. The user must delete all LDs before the optimization mode can be changed, and the CLI will also prompt the user to reset the controller after the mode is changed and before new LDs are created. 1.6.2 contains the fix for the 3310. Current release as of this writing is 2.1.1.

Furthermore, a future 4.0 controller firmware release has the section of code rewritten so that different mode LDs can exist in a controller, thus making problem nonexistent.

This solution has no attachment