SourceForge has been redesigned. Learn more.

#32 badblocks (or a new tool?) - map out a whole zone of sectors


Produce a list of blocks near the bad blocks to map out whole zones of the disk. This can be used to create a one or two dimensional buffer area. Apparently, some drive controllers can do this (described at ). I'm suggesting doing it at the software/OS level.

Allow the 'buffer' region size to be configurable in size (either in megabytes, micrometers/millimeters). Modern drives hide their true cylinder/heads/track information behind the LBA abstraction layer, so handling configurable physical parameters is a bit of a challenge. However justifiable assumptions can be made based on the known or measurable physical characteristics that are not obscured by the LBA abstraction layer.

These known or measurable characteristics include:
1.) drive performance across the whole LBA (the HDTune program on Windows can measure and chart this). This info can help you determine if the drive is likely destroked or not.
2.) drive make and model info. Available from smartctl. An table of drive specs could be kept.
2a.) The table could be used automatically when the tested drive is already in the table.
2b.) The user could manually specify that the tested drive has identical physical parameters to a drive already in the table.
2c.) The user could manually specify parameters for the tested drive
2d.) The user could add drive parameters to the included table, which would be used by the automatic detection mechanism
3.) useful drive parameters (detectable, or in the table, or specified by the user)
3a.) capacity/LBA sectors (from smartctl or table or user)
3b.) physical drive size e.g. 3.5" 2.5" 1.8" (from table or user)
3c.) platter count (from table or user) (useful for knowing how many megabytes per platter)
3d.) head count (from table or user) (maybe useful if some heads are unused or to determine if only one side of a platter is used)
3e.) areal density (e.g.bits/sq. in)(from table or user or calculated) (useful for converting megabytes to millimeters) (Areal density can be estimated from capacity, physical drive size, platter count, and head count; it may be easiest to assume the bits are uniformly distributed per unit area rather than try to account for tracks, and track to track spacing. Estimate of sectors/track and linear bits per inch may be a way to improve accuracy of two dimensional blocking.)

A one dimensional buffer is the easiest as that simply means adding a number of LBA sectors before and after the known bad block. (This assumes that a nearby LBA address is also a nearby physical address on the disk). If specified in megabytes, divide by the sector size (512). If specified in micro/millimeters, use the areal density to calculate the number of bytes per micro/millimeters, then convert bytes into sectors.
(The 3.5" Seagate 7200.12 specs are 2 platters with an areal density of 329 Gigabits/sq. in. A nominal 3.5" disk has 3.74" platters.)


A two dimensional buffer requires more work, and to be certain the two dimensions are covered, the whole track should be included in the buffer along with neighboring tracks. Track length (millimeters) can be estimated based on position on the disk, as it is the circumference of a circle. Calculate the track length from the circumference. Calculate the circumference from the radius. The radius can be estimated based on the LBA and the physical drive size, and possibly also from drive benchmarks run on nearby LBAs. (LBA 0 should be at the inside edge of the disk, with the track it is part of having a diameter ~1". As the LBA # increases, the head moves further out until it eventually reachs the maximum LBA at the end of the disk, where the diamter is about 3.74". Drive performance benchmarks reflect this by starting out fast at the beginning of the disk and slowing near the end, with the drop in performance correlating with how far out the head is. Multiple platters/extra heads affect where each LBA is at.

Caveats include the fact that some bad sectors are actually repairable (by hdparm or other tools) as they may have been caused by a miswritten sector where the sector data and ECC data are out of sync (rather than a media defect).