Defective data sector management system

Electrical computers and digital processing systems: memory – Storage accessing and control – Specific memory composition

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C711S114000, C711S165000, C711S170000, C711S173000, C714S006130, C714S006130, C714S006130, C369S275300

Reexamination Certificate

active

06526476

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to the field of disk drives, and in particular, to a method and system for managing defects in a disk drive system.
BACKGROUND OF THE INVENTION
Modern disk drive systems include multiple disks or platters (known as the disk media) on which data is stored magnetically. Virtually all disk drive media has some defective areas where it is impossible to reliably record (write) or play back (read) data that has been previously recorded. A standard feature of disk drives is to implement some type of defect management scheme, which is designed to avoid these defective areas for the purpose of read/write transfers.
One of the common defect management techniques employed is to simply “slip” defective blocks. This means that in the logical order of how blocks are transferred, certain blocks are simply skipped over. For example, assuming that all blocks on a disk drive have a physical block address (PBA), and all user blocks of the same disk drive have a logical (user) block address (LBA), a drive may be laid out as shown in FIG.
1
. In this simplified example, the drive has 20 physical blocks (
0
through
19
) and 16 user blocks (
0
through
15
). Therefore, up to four blocks can be slipped. The remaining blocks denoted as “R” are reserved for these slips.
To slip a block means to alter the LBA to PBA mapping function such that the PBA block has no LBA, and therefore will not be part of a user transfer. Assuming PBAs
3
and
12
are found to be defective and slipped, the PBA to LBA relationship now becomes as shown in FIG.
2
. The blocks denoted with “S” are the slipped defective blocks, and the blocks denoted “R” are still available for slips.
The major advantage of block slipping is that it introduces minimal performance loss. A multiple sector transfer is only interrupted by a slipped block for the amount of time it takes to go past the slipped block. However, since the slipping of a defective block causes a different logical to physical relationship for all blocks after that defective block, and user data is expected to remain at a given logical block address, this technique requires the moving of all user data after a defective block has been slipped. This is a dangerous procedure since user data can be lost if there is a power or software failure, and furthermore, the time it takes generally makes the procedure prohibitive in the user environment. Therefore, this technique is rarely employed for defects found after the factory test process. It is most commonly used to identify and de-allocate the initial defects on the media before any user data is stored.
Sometimes, additional defects will appear after the factory test process, either due to incomplete defect finding in the factory, defects created because of shock or contamination, or due to environmental conditions or degradation of the magnetics after the disk drive has been placed into service. These defects are commonly referred to as “grown” defects. Since the block slipping technique has the disadvantage of requiring that user data be moved after the slipping operation, typically an alternate method of defect management is employed for grown defects. A common technique is to relocate all transfers directed to a block with a grown defect to an alternate known good block. A few common terms for this technique are “alternating”, “relocating” or “reassigning” a defect.
With this relocating technique, one or more groups of contiguous PBAs are reserved for use as alternate destinations. When a block is relocated, an association is made between it and one of the reserved blocks. Transfers directed to that defective block will thereafter be redirected to the reserved alternate destination block instead. This technique does not affect the physical location of any other user blocks, and therefore it is more suitable for defects found in the field. It has the disadvantage of slower access when the relocated block is part of a multiple block transfer, since a seek operation and/or extra disk revolution(s) are required to get to the alternate block.
FIG. 3
shows an example relationship between PBAs and LBAs with both slipping and a reserved alternate area for future relocations. In this case, PBAs
8
,
9
, and
10
are the reserved alternate area. PBAs
3
and
12
have been slipped. PBA
19
remains available as an alternate area should another block need to be slipped. If, for example, LBA
4
was determined to be defective and in need of relocation, the mapping would change to look like that shown in FIG.
4
. Note that in
FIG. 4
, the technique requires the relocation of only the defective block. Other user blocks are not affected. However, any multiple block transfer that includes LBA
4
must now transfer the blocks out of order, which may entail a seek operation and/or extra disk revolutions, and will degrade performance. Also, any multiple block transfer that is interrupted by the area reserved for alternate destination blocks will incur a performance loss.
Three important factors to consider when implementing a block relocation defect management scheme are the size, location, and number of the areas reserved for alternate destinations. The criteria upon which design decisions are made may include: (1) the disk capacity and expected number of grown defects per unit of capacity; (2) the maximum seek length required to access a relocated block; and (3) the likelihood that the area reserved for alternate destinations will interrupt a multi-block transfer.
The problem is that these parameters are highly dependent on the capacity of the drive and the configuration of the drive (cylinders, heads, sectors, recording zones, frequencies, usable radius and so forth), and many disk drives implement some or all of these parameters in a dynamic fashion. For example, it is common practice for a disk drive manufacturer to produce a line of disk drive products, each model using substantially the same design, but containing a different number of recording heads and/or disks to provide varying capacities to allow the manufacturer to sell the different products at different price points. Lower capacity models are often referred to as “depopulated” disk drives. It is still advantageous, however, to use a common electronics and firmware set for all of the different products, because it simplifies the build process, reduces time to market, and reduces costs. It therefore becomes a requirement of the firmware that it can adapt itself to the capacity of the specific model into which it is installed.
It is also common practice in the disk drive industry to depopulate a disk drive without actually removing any heads or platters. This typically happens in the factory test process when it is determined that a given recording head and surface does not meet specifications, and is therefore unsuitable for the storage of user data. In this case, the disk drive is sold as a lower capacity model. Typically, the test process will record in non-volatile memory on the disk drive (usually the disk) which surface or surfaces are not to be used. The disk drive firmware must be designed to check this non-volatile memory and automatically adjust itself to the depopulated configuration. The alternative would be to change the firmware to a set that specifically avoids the bad surface(s), however, as mentioned above, this adds manufacturing cost because multiple firmware sets must be created and supported.
Similarly, a practice sometimes used is to “short stroke” a disk drive that cannot reliably read and write at the extreme radius of a given surface, thus reducing capacity by not using the outer areas of the media. Instead of not using the entire surface, only a portion of the given surface is unused. Again, the firmware typically must detect this and not use the entire radius of the defective surface, so that the drive can be sold as a lower capacity model.
Another common practice in the disk drive industry is for the factory test process to detect the maximum bit density at which each installed head/media co

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Defective data sector management system does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Defective data sector management system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Defective data sector management system will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3134383

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.