"The Linux Gazette...making Linux just a little more fun!"

Removing Bad Sectors

From Fadel on Fri, 22 Jan 1999

Dear Sir..
How are you? I'm Writing to ask you How can I remove bad sectors HDD? Please reply me as soon as you can.
yours
Fadel

I'm not sure what you mean by "removing bad sectors."

A "bad sector" is a portion on a hard drive we doesn't appear to reliably record data. That is to say that attempts to record test patterns to this location on the disk and read them back result in errors.

Some bad sectors are manufacturers defects on the surface of the disk (generally minor imperfections in the metal-oxide or other coating which is deposited on the disk platter during its manufacture). Before it is shipped a normal hard drive is thoroughly tested on the manufacturer's test harnesses to "map out" the initial set of bad sectors and to ensure that the number of them fell below a suitable threshold.

Back in the old days (about 5 years ago and more) it was common to see the bad sectors listed on a sticker on the drives housing. That was common with MFM and RLL (ST-506 interface) drives. However it is largely unnecessary with modern SCSI and IDE drives.

Modern hard drives have "extra" sectors on every track. These are automatically "mapped in" to replace bad sectors. This happens initially at the factory and (at least with some of them) automatically in normal use. The drive electronics on these sorts of drives are actually embedded microcomputers running a program to store (typically on a "hidden" diagnostics cylinder) the state of the rest of the drive.

Consequently most modern drives leave the factor with no "apparent" bad sectors (and a few extras per track). So they'd rarely need a bad sectors list. (Also if they had one it would be very difficult to use it in mainstream modern operating systems like Window '98 --- which has no option or way for you to supply a list of bad sectors to their disk formatting utilities).

In the case of Linux is is possible to supply such a list. However it is generally much easier to just run 'badblocks' which will scan specified portions of the disk's surface testing every sector and returning a list of bad blocks.

Normally you wouldn't run 'badblocks' yourself. As I've mentioned in past issues of my column, you normally supply -c options to the mke2fs and e2fsck commands (named mkfs.ext2 and fsck.ext2 on some systems). These options force these commands to transparently call 'badblocks', passing in the parameters specifying the partitions (disk regions) and reading back the results (the bad blocks). The resulting list of bad blocks is then stored according to the needs of the filesystem in question (ext2 in this case).

The ext2 filesystem uses a special sort of "hidden file" to which it allocates all of the bad blocks on the filesystem. The insures that those data blocks (sectors) will never be accessed or used for any other files.

Under MS-DOS we used to manually name files suspected of containing a bad block (those which would cause the whole system to "hang" when we'd attempt to access them) with a name like BADBLOCK.001. Later Peter Norton, Paul Mace and others wrote utilities to help use test for and properly mark bad blocks.

Now, if you mean that you want to return badblocks to use I suppose the easiest method would be to make a new filesystem over the one that has the bad blocks. You could run mke2fs without the -c option and let it trip over any bad blocks on it's own. If there are blocks that were properly detected as 'bad' before --- it's typically a VERY BAD idea to try to use them to store data later. You can't selectively use the 'bad blocks' for "unimportant" data and you can't guarantee that the controller won't hang up the whole system (or drastically hurt its performance) during attempts to access these. (Sometimes blocks are "marginal" --- data can be stored there and read back with some retries and error correction. All hard drives use ECC --- error correction coding and automatically correct most bit errors in normal operation. However, a block is declared 'bad' when it passes certain thresholds, always requiring ECC and often requiring multiple retries. I don't know the exact details of those thresholds --- but they certainly differ among various drive manufacturers).

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999

				1	2	3	4	5	6	7	8	9	10
				11	12	14	15	16	17	18	19	21	22
				23	28	29	30	31	32	33	34	37	38
39	41	42	43	44	45	46	47	48	49