0

I have faulty 3 Tb drive. There's a lot of bad blocks, but it's still has about 2.6 Tb usable space and I'd like to utilize it for trash storage (music, videos, etc.) At first I came across some guy's manual. He cut disk into several partitions and then made JBOD (just bunch of disks) RAID (if you're intrested there's a link(russian): https://habr.com/ru/post/252211). But someone in comments of that article mentioned that the same can be done by the mkfs itself with '-c' key. And now I wonder, how does it work? Yes, there is a man page, which tells us:

-c Check the device for bad blocks before creating the file system. If this option is specified twice, then a slower read-write test is used instead of a fast read-only test.

There is an arch wiki article which tells almost the same. It checks device for bad blocks, and then what? People here and there in the Internet say that it marks bad blocks and OS doesn't use them. How can I check it? Is there any utility, which shows marked out blocks for further use (future partitions creation, maybe)?

agp22888
  • 3
  • 2
  • mkfs -c has to be run once for each partition created. mkfs does not work the same way because it doesn't create a RAID at all. However, both methods **hide** the bad sectors. – cybernard Mar 25 '19 at 20:09
  • @cybernard is there any way to extract data about bad blocks from created partition? – agp22888 Mar 25 '19 at 20:26
  • try this: badblocks /dev/sda2 -v -o filename_to_output.txt replacing sda2 with your device. It will take hours to scan the disk. – cybernard Mar 25 '19 at 20:34
  • 1
    When a drive starts developing bad blocks that it does not revector, it's time to scrap the drive no matter how big it is or how much it originally cost. Un-revectored bad blocks are a sign that the drive is well into surface failure and the situation will only get worse. –  Mar 25 '19 at 21:25

1 Answers1

2

It's true man mkfs.ext4 (man 8 mke2fs) says what you cited:

-c
Check the device for bad blocks before creating the file system. If this option is specified twice, then a slower read-write test is used instead of a fast read-only test.

But there's also -l:

-l filename
Read the bad blocks list from filename. Note that the block numbers in the bad block list must be generated using the same block size as used by mke2fs. As a result, the -c option to mke2fs is a much simpler and less error-prone method of checking a disk for bad blocks before formatting it, as mke2fs will automatically pass the correct parameters to the badblocks program.

So let's investigate man 8 badblocks:

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.

It mentions e2fsck (aka fsck.ext4 in case of ext4), so let's check man 8 e2fsck [emphasis mine]:

-c
This option causes e2fsck to use badblocks(8) program to do a read-only scan of the device in order to find any bad blocks. If any bad blocks are found, they are added to the bad block inode to prevent them from being allocated to a file or directory. If this option is specified twice, then the bad block scan will be done using a non-destructive read-write test.

And since mke2fs and e2fsck are parts of the same toolkit, I expect -c in mke2fs to work in the same way despite the fact its description doesn't state this explicitly.

Then to check bad blocks the filesystem knows about use dumpe2fs. From man 8 dumpe2fs:

-b
print the blocks which are reserved as bad in the filesystem.

(credits to this answer).

Note it's the filesystem that stores the information. To use it for future filesystem(s) you need to save it before you destroy the current one. And if you change the partition table or choose different block size for a new filesystem then you will need to recalculate the numbers.

Kamil Maciorowski
  • 69,815
  • 22
  • 136
  • 202