4

I have a SATA HDD, which has bad sectors. I do not need the data, and need to format the HDD to create a fresh device.

I tried to repair the HDD problem with commands like

fsck.ext4 -p /dev/sda1

but it takes ages to fix the sectors. I formatted the entire HDD, but still have the problems. Is there a quick way to format the HDD and restore bad sectors?

6

No, there is no quick way. Generally, when you have a disk with some bad sectors, you should overwrite the total contents of your disk, with a command similar to this:

dd bs=512k if=/dev/zero of=/dev/...

It'll take some time (2-3 hours normally). Doing this will give your disk a chance to handle bad sectors. A modern disk (made in the last ~15 years) handles bad sectors internally, transparently remapping those sectors from a reserved set of sectors during writes. So in the end, you should have a disk with all sectors usable. If the disk cannot do this remapping, it usually means that there are so many bad sectors that it ran out of reserved sectors. This is a clear indication that the disk has reached end of life.

6

A bad sector (a sector is an old term, nowadays 'block' is more commonly used) on a HDD means one or more bad blocks are of out of spec on the disk magnetic surface area. The only way to locate those blocks is to try to read every single block on a hard drive. HDDs are slow so that will take a lot of time.

For example, a modern HDD has real world read throughput around 130 MB/s, so a modern 4TB disk will take around 4000000MB / 130MB/s = 8.5h to even read the whole disk once without bad blocks. A drive with one or more bad blocks will cause drive to try re-read those blocks repeatedly so the throughput will suffer a lot. That will allow you to locate the bad blocks that cause read errors. Getting any modern HDD to remap a bad block requires writing something to that bad block.

The only way to really test if a block of HDD surface works is to read that block, then write it back, and then see if the drive still says everything is okay for that block. Blocks used to be 512 bytes long but modern drives use 4KB blocks internally. A modern 4TB drive requires testing around a billion (1e9) 4KB blocks. And did I mention that HDDs are slow?

If you have bad blocks and any data, you really want fsck.ext4 -cc. And that one will take around a day or two at minimum. Doing fsck.ext4 -c will allow ext4 to avoid the bad blocks but it cannot fix the drive. The -c option of fsck.ext4 makes it to try read every block on the partition. The -cc option will make it to try read every block and the write the same contents back to the drive and check for errors. And even disks where -cc fails can be repaired sometimes... However, there is not a magic bullet to locate the bad blocks. The only way is to scan the whole drive and it will be slow with huge drives.

Since you don't need any data, doing sudo dd if=/dev/zero of=/dev/sdX bs=4M will allow skipping the "read the data" part and going directly to "fix the blocks" part. And that will still take somewhere between 8-20 hours to complete.

Note that the drive firmware will fix the bad block automatically once you overwrite the bad block. It really does not matter which OS or tool you use to overwrite a bad block on a HDD. And the data does not matter either. If the drive cannot fix any given bad block, that drive is done. This is because modern hard drives have some extra physical blocks in reserve that are used to fill bad blocks in the logical address space. If a bad block cannot be fixed, it's only because the all the blocks in the reserve space have already been used! The drive has been failing for a long time already in that case.

Note that you have to use correct blocksize to fix the block. For example, if your drive uses 4KB physical blocks and still allows 512B logical blocks, you cannot overwrite a bad block with a 512B logical write, because the drive will technically try to read the real 4KB block, alter the 512B you wrote and the re-write the 4KB block back to the magnetic plattern. Obviously the "read the real 4KB" will fail if the physical 4KB block is bad. The way to avoid that is to write the whole 4KB block in a single HDD command so nothing needs to be read from the physical disk. In the end, you have to write a correctly aligned 4KB block to fix given bad block. The dd command above will always write 4MB blocks, which will be correctly aligned if you use whole device as of target (you can use any multiple of 4 KB for writing, above example uses 4 MB to improve performance). If you use a single partition as the target and that partition is not correctly aligned, that command may still fail to fix bad blocks if logical and physical block sizes do not match for the drive. As far as I know, this is true for most modern HDDs. Executing smartctl -x /dev/sdX will give info about device sdX.

As always, do man fsck.ext4, man dd and man smartctl before messing with this stuff.

2
  • I would like to mention SpinRite, a proprietary DOS/Windows software, that tries to be smart and thorough about this basic idea of reading a sector and writing it back. I've witnessed first hand that it was able to fix the drive where badblocks/e2fsck -cc and dd failed. That said, however, it was able to prolong that particular drive's life by another month only. YMMV.
    – ILIV
    Jan 22 '18 at 7:45
  • AFAIK, SpinRite does extra "magic" for the reading the disk part but otherwise it behaves technically identical to dd. The "magic" it does contains trying to read the bad block immediately after different seeks. In theory this causes the read head to position ever so slightly differently each time and hopefully one position allows reading the data. If you don't need the data and can proceed with simple overwrite, you should definitely skip the reading part because that's the really slow part. As I wrote above, a modern drive will fix itself if you overwrite the bad block. All done by hardware. Jan 23 '18 at 8:18
1

Al depending on the drive make. You can download from the drive manufacturer website, tools that can to a certain extend repair the drive.

Seagate drives

Western Digital

1
badblocks -wsv -o /root/<badblocks.txt> /dev/<device>

mkfs.<filesystem-type> -l /root/<badblocks.txt> /dev/<device>

3
  • 5
    Can you edit the answer to elaborate on this a little? Thanks.
    – fixer1234
    Mar 30 '17 at 7:39
  • 1
    Essentially, this is an equivalent of e2fsck -cc command. It does the same thing. In fact, it is recommended for most users to use e2fsck over badblocks. Quoting badblocks man page: "Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important that the block size is properly specified, since the block numbers which are generated are very dependent on the block size in use by the filesystem. For this reason, it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs."
    – ILIV
    Jan 22 '18 at 7:41
  • 1
    WARNING Never use the -w option on a device containing an existing file system. This option erases data! -- from man badblocks, man7.org/linux/man-pages/man8/badblocks.8.html
    – Avtokod
    Oct 1 '19 at 7:21
1

First of all, a bad sector, in theory, would mean permanent damage to parts of a hard drive. So if you are planning to use this drive for important data towards the near future, perhaps reconsider that. The chances for the bad sectors to increase are good. As far as I know, there is no real way to actually fix bad sectors. Only prevent them from being used. Also, you need to keep in mind that file systems may be written in partitions. To view a list of partitions, use the fdisk -l command. Then you can use e2fsck -c command to prevent bad blocks to be allocated to a file or directory.

1
  • It really depends on the original cause for the bad block. If the cause is microscopic manufacturing defect on one surface of the disk, the changes are high that this is the only problem you'll hit with the drive. I'm still running a disk in my workstation that had one bad block around 5 years ago and I was able to overwrite that bad block with dd .. bs=4k count=1. According to smartctl -x only one sector has ever been relocated (the one I fixed with dd). I'm using this "broken" drive as a backup for my SSD data. Jan 23 '18 at 8:23
1

Whether a drive is about to fail depends entirely on how the bad blocks came about, if you have a few strays in not the usual places they could be the result of power issues or never had a full format since new. Heavily used drives will usually have several bad blocks in beginning, middle and sometimes end. NTFS does the journal at the start and bitmap in the middle, the end I'm assuming is a spare/remap function as they weren't associated with tracking or fly height errors. Sometimes there can be random patches if there was a frequent file rewrite in the same place, more often seen in data drives rather than boot.

Low level format only got a bad name by those misusing it, map those bad blocks before allowing anything automatic to take place and save smart data. If there's a heavy cluster, map around the entire thing, it was either journaled to death or victim to a recycling log and blocks amidst and near by are likely to fail soon. It should be something like this whether you exclude via low level format or via partitioning. bad blocks

I haven't done it commercially but have for various people, as I don't know the full results other than not getting complaints I'll detail those I've been personally involved with long term.

First was a heavily used maxstor 160gb ide, it was near 6 digits on the failed blocks, the graphic mapping was either Fujitsu, Samsung or Toshiba drive tools and I had to enter manually in the Maxstor sw to exclude. I had to skip Maxstor auto function as it locked over 10k bad blocks or so. I literally measured the graphic map with a ruler on the screen and translated that to the lba addresses. I ended up removing the first 20gb and 20gb near the exact middle, used it for 5-6 years as a boot drive and served almost 10 more in an enclosure as a 120gb, it even presented to bios and os as 120gb.

Second was a Samsung Spinpoint 2tb, I think that was 80gb at start, 100gb middle and 20gb at end. I don't remember if I excluded low level or joined the 2 partitions via software. I did however use it for 5 years capping TV and security cams, 30-150gb per night.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.