SeaTools for DOS is a tool that can "repair" bad sectors on your hard disk. But because it's DOS and all, it's uncomfortable to use now. This post shows how to do the same with other tools.

What does SeaTools when repairing a bad sector?

When using "Basic Tests -> Long Test" in SeaTools for DOS, it may find bad sectors if there are any, and finally (after one info screen) present you with a list of them and the option to "repair" them. This is actually remapping the logical block on the hard disk not to this sector, but to a spare one. The SeaTools for DOS documentation reads:

"If you have decided that the file or folder is replaceable, already backed up or just not important to you, then you can tell SeaTools to attempt to overwrite the sector. […] If you give permission to overwrite a bad sector SeaTools will attempt to write a pattern of zeros to that sector. Usually, this action will assist the disk drive firmware in managing the problem by retiring the problem LBA and activating a spare in its place." [SeaTools for DOS User Guide, Rev 31-Dec-2010, 4. Help Topic: "Bad Sector Found"]

This seems to mean that SeaTools for DOS just tries to write to the bad LBA, which will then trigger it to be reallocated to a different physical sector by the drive's firmware. So SeaTools would not do any special proprietary thing to reallocate sectors or rescue your data, but just do something to trigger the disk's firmware's standard procedure for sector reallocation, as explained by Wikipedia:

"Typically, automatic remapping of sectors only happens when a sector is written to. The logic behind this is presumably that even if a sector cannot be read normally, it may still be readable with data recovery methods. However, if a drive knows that a sector is bad and the drive's controller receives a command to write over it, it will not reuse that sector and will instead remap it to one of its spare-sector regions." [Wikipedia: Bad Sector]

While the usual procedure to force "pending" bad sectors to be remapped is to do a low-level format (overwriting the whole disk with zeros, like with dd), it seems from what SeaTools does that overwriting the sectors in question is sufficient.

How do we do the same?

Using dd

Probably you do not need SeaTools for remapping a defective sector, you could just as well use the Linux utility dd to trigger writing to the bad sector, like this:

1. Get the sector number (LBA, not physical) of the bad sector (here, 1234567).
2. Execute the following dd command, replacing /dev/sdb with your device in question:
   sudo dd bs=4096 seek=$((1234567/8)) count=1 if=/dev/zero of=/dev/sdb

Note that in the above example, we write one sector (512 bytes) only; to not overwrite more than this one sector. Note also, "seek" gives the number of blocks to skip, but as the LBA number is counted from zero, LBA 1234567 is actuall block no. 1234568, which means we need to skip one less than this to write to it, which is again 1234567.

Another note: normally you would expect writing one block of sector size (bs=512), instead of effectively 8 of them by using a block of size bs=4096. However, writing a sector-sized block does not work for some reason:

$ sudo dd bs=512 seek=231588920 count=1 if=/dev/zero of=/dev/sdb
dd: writing `/dev/sdc': Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 2.32662 s, 0.0 kB/s

The existence of one bad sector means that you can only overwrite it (to trigger sector remapping) with blocks in filesystem block size, here 4096 [source: "reallocate bad block writing zeros in it, using the fs block size", in Bad block HOWTO for smartmontools: Repairs at the disk level: LVM repairs]. I currently have no idea why file system block size would have any impact here; perhaps this does not mean the file system of /dev/sdb, but of /dev/zero, which might also be a block device (but probably is not, but a character device)?

Anyway, this tip makes the process work. I tried ddrescue again afterwards, and no bad sector errors were found now. Which means, the disk indeed remapped the bad sectors. And after that, dd can write with bs=512 to the device – it only is impossible when trying to write to bad sectors, as it does not trigger remapping for some reason.

Using sg_reassign and sg_verify

There is a more professional-looking way of fixing bad sectors, using sg_reassign and sg_verify, as described in Bad block HOWTO for smartmontools: Repairs at the disk level: Bad block reassignment. Especially useful for batch processing many bad sectors.

Using hdparm

As noted by Ben in the comments, hdparm --repair-sector will write zeros to the given sector (using a low-level write routine which bypasses the usual block layer). This will force the drive to "repair" the bad sector by remapping the block to a spare sector.

Performance effects of sector remapping

Wikipedia reads on this:

"As the count of reallocated sectors increases, the read/write speed tends to become worse because the drive head is forced to seek to the reserved area whenever a remap is accessed. A workaround which will preserve drive speed at the expense of capacity is to create a disk partition over the region which contains remaps and instruct the operating system to not use that partition." [Wikipedia: S.M.A.R.T.]

This implies that all sector remapping triggered by writing to bad sectors is done via the G-list, not the P-list (definitions: [Wikipedia: Bad Sector]). Because it is said that remappings via the P-list have no performance penalty, but are only possible with more professional tools [hddlab.de: Festplatte reparieren: Oberflächenschäden in der User Area].