[Solved]: Bad block on backup superblock

I have a generic hardware problem not specific to NRR. Kindly redirect me elsewhere if this forum is not appropriate.

After a re-installation, I re-partitioned the remainder of my system disk into a single large ext4 partition: let us call it /dev/sda3 (/home is on another drive).

Every few boots, I encountered an error mounting /dev/sda3, and boot would drop into a root shell. I tried fsck repairs twice but on the third occurrence, I decided to bite the bullet and format afresh the filesystem on that partition, more carefully and slowly.

I tried

sudo mkfs.etx4 -ccFv -L Data1 /dev/sda3

and got the following output:

[code]mke2fs 1.42.13 (17-May-2015)

/dev/sda3 contains a ext4 file system
created on Wed Feb 24 09:07:15 2016
fs_types for mke2fs.conf resolution: ‘ext4’
Filesystem label=Data1
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
27197440 inodes, 108783616 blocks
5439180 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
3320 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Filesystem UUID: 3fd692fc-7ce0-443d-bc92-8b775b95551e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,

Running command: badblocks -b 4096 -X -s -w /dev/sda3 108783615
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff:done
Reading and comparing: done
Testing with pattern 0x00:done
Reading and comparing: done
Warning: the backup superblock/group descriptors at block 31457280 contain
bad blocks.

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done[/code]
Given the warning, I have these questions:

  1. Can I now use this newly formatted partition reliably, without losing data or encountering boot problems? (It took more than 10 hours to format it!)

  2. If not, should I divide /dev/sda3 into two smaller partitions to avoid the bad blocks, and if so, how should I do it? (I am unfamiliar with disk geometries, etc.)

  3. Or, should I replace the system disk instead? (It is 500 GB and would be wasted if I did not use the rest of it, despite the system partition on /dev/sda1 being robust at present.)

I would first open up partition manager and check the S.M.A.R.T. status of the drive in question.
If that is fine then I would sugest backing up your data, then wipe and repartition the drive just to be sure.
The fact it took that long to format a 500 gig drive would be a red flag for me.

Thanks, AJSlye. I was not aware of the SMART monitor option in the KDE Partition Manager. The results for /dev/sda seem encouraging (see attached screenshot).

The inordinately long time for formatting that I reported is because of the exhaustive read-write-compare tests using four patterns, arising from the repeated cc option for mkfs.ext4, if I understand it correctly.

Repartitioning the whole disk means that I must backup the root partition as well. I have previously only backed up /home and my data. Are there any special precautions for backing up the root partition? Will a simple

rsync -aAXv // /path/to/my/root/backup

suffice or must I try something else, like unison? Also, to restore, do I simply interchange source and destination? What about grub settings? I would like to avoid a total re-install from disk if I could.

Finally, are there any precautions when re-partitioning or before re-partitioning. (Just to be sure, I have swapped the data cable to the SATA drive with another one, and ensured that it well and truly clicks into place.)


The root partition is not that important to backup unless you have something special there, the new Install will write this for you. Personally, If you really need to keep everything then I would recommend clonezilla to backup the drive. If it was just a bad backup copy of the superblock I wouldn’t be too concerned. However, since it’s actually sitting on a bad block, I wouldn’t take too many chances with it. One bad block usually means there are more that just haven’t been found yet, a full wipe would force S.M.A.R.T. (the drives firmware) to discover and remap any bad blocks it finds.

Thanks. I have followed your suggestions and got something stable for now. THe SMART test results are a boon!

Alas, I now need to do the same for the disk on which /home is sitting. I think I might have reached the MTBF for the hard disks!

EDIT: It appears that the bad blocks are persistent and that repeated formats lead to worse SMART statistics. So a new disk it will have to be. Shame!