Sun Storage Flexline 240 Array
 
Sun Storage Flexline 380 Array
 
Sun Storage 6580 Array
 
Sun Storage Common Array Manager (CAM)
 
Sun Storage 2540-M2 Array
 
Sun Storage Flexline 280 Array
 
Sun Storage 6130 Array
 
Sun Storage 2540 Array
 
Sun Storage 6180 Array
 
Sun Storage 6540 Array
 
Sun Storage 2510 Array
 
Sun Storage 6780 Array
 
Sun Storage 2530-M2 Array
 
Sun Storage 2530 Array
 
Sun Storage 6140 Array
 

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

Applies to:

Symptoms

A critical fault is generated similar to the following:

Cause

The term "unreadable sector" refers to a volume logical block address that has been rendered completely unreadable due to a disk media-related double fault condition on redundant volumes, or a disk media-related single fault condition on non-redundant volumes (RAID 0). Any user data contained within the unreadable sector is unrecoverable and should be considered lost. (These types of faults are more commonly referred to as "a two disk failure in a Raid 5" or a "read error on a raid 0")

Once an unreadable sector is detected and an entry is placed in the database for it, all future reads to that sector result in a media error being returned for the read. The entries in the database persist until the affected sectors are written by a host or internal write command, or explicitly cleared by a user action.

Solution

The unreadable sector database is used to count the number of logical block allocations (LBA) on a given volume. It can only hold around 1024 entries total.

1.  Verify the Critical Fault.

Refer <Document 1021057.1> Sun Storage Common Array Manager (CAM): How to Verify Critical Faults for Sun Storage 2500, 2500-M2, 6000 and J4000 Arrays.

• If you have a 66.1074 or 66.1075 critical fault, continue to Step 2.
• If you do not have one of these faults, then the array has not detected any data loss, and no further work is required.

2.  Identify the Volume(s) that have the unreadable sectors. 

This can only be viewed by looking at the appropriate file collected within a supportdata.   Collect this data and unzip it.

• Refer <Document 1014074.1> Collecting Support Data for Arrays Using Sun StorageTek[TM] SANtricity Storage Manager.
• Refer <Document 1002514.1> Collecting Sun StorageTek[TM] Common Array Manager Array Support Data.

This first example comes from a supportdata created with SANtricity. The unzipped file is called unreadableSectors.txt. We see PHYSICAL errors to disk drive 85.5

This second example comes from a supportdata created by CAM. The unzipped file is called badBlocksData.txt. In this file we see multiple LOGICAL errors to disk 85.5

If the badBlocksData.txt file or the unreadableSectors.txt files do not have any entries, collect a supportdata and contact Oracle support for further instruction. Otherwise, proceed to step 3.

There are certain circumstances where the badBlocksData.txt or unreadableSectors.txt files will be empty, but the alarm still exists. When this is the case, use the following shell procedure to clear the alarm from the array.

This first command will report all alarms on the array.  Its possible that only one controller is reporting the alarm. Subsequent repairs should be run from that controller.

See if there are stale entries in the unreadable sectors database.

06.xx.xx.xx firmware

07.xx.xx.xx firmware

Clear the entries form the database.

If the problem still persists, Fix any alarms for Volumes Not On Preferred Path, and repeat the procedure. You may also need to reboot the controller reporting the alarm.

3.  Recover and Restore the volume(s) that have the LBA errors

The data in these volumes is considered corrupt and should be restored.  Whether this has impacted any application or not is unknown; however the data needs to be restored to recover the fault.  Once the blocks have been written to again, the entries will be removed from the list and the fault will clear.

If there are other faults for drive failures for the same volumes, then these should be handled prior to the restore of the data.  Any subsequent writes will cause any drives that may be marginal to fail for replacement.

Once a restore has been completed for all volumes affected, continue to Step 4.

In theory, the unreadable sectors could very well be in a non-data resident piece of the Raid Volume.  When this is the case, data may actually be intact. For situations when a restore is not a viable solution, a server side check of the data may be an option. For example, a successful Solaris fsck of the UFS or VxFS file system, or a successful zpool scrub of the ZFS file system may be enough proof that the data is valid. If this is true, then a restore is not required.

4.  Clear the unreadable sectors list if it has not been cleared by Step 3

Clear the alarm with the CAM GUI

1. Start Common Array Manager and Select the Array.
2. Launch the Service Advisor utility found in the upper right hand corner.
3. Open up -> Recovering from Unreadable Sectors
4. Select  -> The volume
5. Follow the Instructions, including the item to -> Clear Unreadable Sector Database.
6. Exit Service Advisor

Clearing the alarm with the cli.

          Get the array name.

1. 
   Example:
   
   # sscs list array
   Array: myarray
   # 
2. Clear the unreadable sectors list.
   
   
   service -d <arrayname> -c reset -q usm -t <volume name>
   
   
   Example:
   
   
   # service -d myarray -c reset -q usm -t myvol

Clearing the alarm with SANtricity

1. Open the Array Management Window.
2. Open the Advanced Menu.
3. Open the recovery Sub-Menu.
4. Select "unreadable sectors".
5. Select all and clear them.

If the issue persists, collect a supportData and contact Oracle Support:

• Refer <Document 1014074.1> Collecting Support Data for Arrays Using Sun StorageTek[TM] SANtricity Storage Manager.
• Refer <Document 1002514.1> Collecting Sun StorageTek[TM] Common Array Manager Array Support Data.

References

This solution has no attachment