0

UDisk shows the assessment on my disk

Disk is OK, 19 bad sectors (24° C / 75° F)

This number has remained unchanged for one years long, so I guess my disk is not going to fail, but bad sectors cause my system to crash. Can my Ext4 filesystem ignore them without formatting?

1
  • I've found no relevant options in tune2fs, so reformatting seems like the only option. Jan 11, 2021 at 9:59

2 Answers 2

3

Yes, your ext4 filesystem can ignore them without formatting.

But unless you have a really really old harddisk, you'll probably have a harddisk that automatically re-allocates bad sectors to "spare" sectors on the next write, all transparently to the OS.

So the proper way is to get a bad block list, try to read each of those several times just in case, and then write it back (or zero it if you can't read it; in that case you might also want to identify the file, and see if you can't restore it from somewhere). You can do this e.g. with dd (but double check everything before you hit return, it's easy to do stupid things with dd and direct writes to hard drives or partitions).

While you are at it, also check the SMART data of your harddrive with smartctl.

4
  • So the proper way is to get a bad block list, try to read each of those several times just in case, and then write it back - this may or may not work and doesn't solve the issue the OP has. And when it doesn't work, you're screwed because your FS may fail in various unpredictable ways. Jan 11, 2021 at 13:50
  • Just for those wondering what "really really old" means in this context, it means HDDs older than 20 years or so. Likely not many of them still in operation.
    – TooTea
    Jan 11, 2021 at 16:24
  • So my disk has problem.
    – user450522
    Jan 14, 2021 at 12:06
  • Your disk does not necessarily have a problem. A few bad sectors on modern disks are no cause for concern, given the density. What do the SMART values show?
    – dirkt
    Jan 14, 2021 at 12:20
2

You can run fsck.ext2 with the -c option, which will run badblocks, create an invisible file with the blocks that fail to read, and then make sure that no two files share the same blocks. If any of these blocks are in use by another file, this shows up as a conflict, and you are given various repair options like trying to duplicate the blocks, or deleting the file.

That kind of repair cannot be performed during an automatic (-a) run, because it involves a destructive operation. If you combine -c and -a, the file system check can fail, and I'm not sure if the bad blocks inode is properly constructed in that run (it should be, so you should be able to then do an interactive repair without repeating the scan).

That way, these blocks are marked as allocated and will not be used.

1
  • If the bad blocks are already known, it is also possible to run e2fsck {-l|-L <bad_blocks_filename>} to specify a filename that has a list of bad blocks (one block number per line in ASCII format).
    – LustreOne
    Jan 12, 2021 at 19:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .