154
APPENDIX
it is found to have a defect, data will be automatically relocated,
and the defective location is mapped out to prevent future write
attempts.
In the event of an unrecoverable read error, the error will be re-
ported to the host and the location will be flagged as being po
-
tentially defective. A subsequent write to that location will initiate
a sector test and relocation should that location prove to have
a defect. Auto Reassign Sector does not affect disk subsystem
performance because it runs as a background task. Auto Reassign
Sector discontinues when the operating system makes a request.
•
Consistency Check
A consistency check is a process that verifies the integrity of
redundant data. To verify RAID 3, 5, and 6 redundancy, a con-
sistency check reads all associated data blocks, computes parity,
reads parity, and verifies that the computed parity matches the
read parity.
Consistency checks are very important because they detect and
correct parity errors or bad disk blocks in the drive. A consistency
check forces every block on a volume to be read, and any bad
blocks are marked; those blocks are not used again. This is criti-
cal and important because a bad disk block can prevent a disk
rebuild from completing. We strongly recommend that you run
consistency checks on a regular basis—at least once per week.
Note that consistency checks degrade performance, so you should
run them when the system load can tolerate it.
Data Protection
•
Recovery ROM
The RAID subsystem firmware is stored on the flash ROM and is
executed by the I/O processor. The firmware can also be updated
through the RAID subsystems RS-232 port or Ethernet port with-
out the need to replace any hardware chips. During the control-
ler firmware upgrade flash process, it is possible for a problem to
occur resulting in corruption of the controller firmware. With our