Asset ID: |
1-79-1498412.1 |
Update Date: | 2016-09-14 |
Keywords: | |
Solution Type
Predictive Self-Healing Sure
Solution
1498412.1
:
Pillar Axiom : Explanation of Bad Blocks , BBL entries
Related Items |
- Pillar Axiom 300 Storage System
- Pillar Axiom 600 Storage System
- Pillar Axiom 500 Storage System
|
Related Categories |
- PLA-Support>Sun Systems>DISK>Axiom>SN-DK: Ax600
|
An explanation of how bad blocks appear and why they are inherited from copid/migrated LUNs.
In this Document
Applies to:
Pillar Axiom 300 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Pillar Axiom 500 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Pillar Axiom 600 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Information in this document applies to any platform.
Purpose
An explanation of how bad blocks appear and why they are inherited from copied/migrated LUNs.
Scope
This article is written to any TSE willing to understand how BBL entries happens and how the brick deals with bad blocks on disks.
Details

strip: also called block by other vendors, this is the smallest allocated chunk of disk this is a collection of 256 LBAs (or 256 sectors) or 128Kb
stripe: a collection of one strip on each disk in the same RAID group, 6 strips for SATA/SSD bricks and 11 strips for FC bricks
MAU: Minimum Allocation Unit; the minimum allocated user data chunk for a LUN. A MAU is a collection of 420 stripes. The RAID protection is performed at the MAU level.
BBL: Bad Block List; the list of bad blocks that is kept in the persistent memory of the RAID controllers.
LBA: Logical Block Address; the cylinder, head and sector physical address on the disk.
DIL: Data Integrity Lock, This is a Pillar RAID mechanism that allow the brick to put a stripe on hold while repairing damaged sectors on a disk.
Sector Repair: process of rebuilding a sector's data from parity for a RAID5 or by getting the data in the mirrored sector for a RAID10
At the single disk level
Modern hard drive have a reserve pool of sectors to manage the normal deterioration of the disk surface during its life span.
There is 2 types of sector lists; the P and G.
The P list is the primary list of sectors that is factory filled. When the disk is factory initialized, some sectors may already be defective and are then put in the P list. This does not matter much as all sectors are contiguous and completely transparent for the data access.
The G list is the grown defect list and defective sector numbers are filled in this list when the disk firmware detects a faulty sector. The sector is then relocated ONLY during the next write.
When the block is overwritten, the block is then copied in the reserve area. As the number of relocated blocks increases, it can lead to performance issues as the disk has to seek longer to access sectors at different places on the disk.
At the brick level
Bad block List
Bad blocks are most likely to occur when a disk fails, and a rebuild is triggered. A new disk is inserted but some bad sectors on the surviving disks make the parity calculation impossible to repair sectors. These bad sectors are then added to the BBL list.
If the requested LBA(s) by a host are in the BBL, the brick firmware will send an SCSI Media Error rather than going and fetch the data.
Even when a BBL entry is added, it does not necessarily mean that customer's data is affected; this bad block could be in reserved space such at the drive integrity log area, or an unwritten part of an allocated LUN.
Bad Blocks can also be repaired. When a write happens in the same LBA range of the affected block, the data will be rewritten, the stripe will get cleaned up and the BBL entry removed from the list.
LUN Copy and Migration:
When a LUN is copied or migrated, the copy of the LUN is done in block mode and the LBAs in the BBL are not copied. The new LUN inherits the bad block list in the LUN's Array Manager (AM) metadata. These flags will only be removed once all the blocks in the BBL are overwritten.
Brick proactive mechanism:
When a read error happen on a disk, the brick will invoke a sector repair routine where the RAID firmware will recalculate the sector data from parity in RAID 5 or get the data from the mirrored sector in RAID 10 and overwrite the bad block.
This will place the sector in the G list of the disk.
The brick scrubs background utility periodically scans all disks for media errors in order to proactively correct any defective sectors.
When a bad sector is encountered on a disk being scrubbed, the RAID firmware will invoke the sector repair routine.
Solution:
In order to permanently remove bad blocks from a disk. the data needs to be overwritten.
The customer can run a host based integrity scan of the data LUNs and see if there are any read errors and correct them if it can. Most operating systems have some kind of utility for checking data. If this process fails, a the user data must be restored from backup and overwrite the affected LBA range.
References
<NOTE:1531909.1> - Pillar Axiom: How to do reverse mapping to find LUNs affected by bad blocks
Attachments
This solution has no attachment