Suppose there's a hard drive /dev/sda, and both that:

  • /dev/sda1 is a single ext4 partition taking up the whole disk, and it's mostly empty of data.
  • dumpe2fs -b /dev/sda1 outputs the badblocks list, which in this case outputs single high number b representing a bad block near the end of /dev/sda; b is fortunately not part of any file.

Now a swap partition needs to be added to the beginning of /dev/sda1, and gparted (v0.30.0-3ubuntu1) is used to:

  • Resize (shrink) sda1, so that it starts several gigabytes later, but ends at the same place.
  • Add a swap partition in the gap left by shrinking sda1.

So gparted finishes the job and we run dumpe2fs -b /dev/sda1 again. What happens? Does it...?

  1. Output nothing, meaning the resize forgot the bad block.
  2. Output b unchanged.
  3. Output b + o where o is an offset corresponding to where the just shrunk /dev/sda1 now begins.

NOTE: To simplify the question, suppose that the hard disk in question has no S.M.A.R.T. firmware. (Comments about firmware are off-topic.)

  • gparted is using other command line tools to resize the file system in partition. Whatever happens to the bad block list will depend on how these tools are called (and I'm too lazy to read the gparted source code to find out details). Anyhow, modern harddisks transparently remap bad blocks to spare blocks, so bad block lists have become useless, and you shouldn't use them. (And the bad block may be overwritten during the resize). So the question is somewhat academic. (And if you are absolutely interested in the answer, why not try it yourself?). – dirkt Dec 13 '18 at 9:15
  • @dirkt, All valid points, were HD BIOS remapping not off-topic of course. There are some speculatively pragmatic reasons to exclude remapping, (HD BIOSes are binary blobs, it's not inconceivable that one might be buggy and do a bad job or even harbor imperfect and therefore detectable malware or spyware), but those too would be off topic. Time to buff my tinfoil hat... – agc Dec 14 '18 at 1:52
  • It's not "BIOS" remapping. It's done in the firmware of the harddrive (which is not the Basic Input Output System). And it's independent of any SMART features. Of course you can declare that off-topic, but it's a fact that modern harddisks do this, and if you use a bad-block list, you'll waste a block address that will be perfectly fine after the next write. And not even do you waste it, you are bothered what will happen to it under odd circumstances. Which is what you call an "academic question". – dirkt Dec 14 '18 at 6:54
  • If you are really worried about the bad block list after re-arranging partitions, just do the re-arranging manually (not with gparted), and do a bad block scan again afterwards. But that was not your question, I know. – dirkt Dec 14 '18 at 6:56
  • @dirkt, Thanks. Good call about conflating the specific terms BIOS and SMART with the more general term firmware, (and the lower level remapping firmware). FWIW I'm not personally worried about firmware security, (that'd be more of a public hazard), so much as skeptical that a drive's firmware is bug-free, (or if its checking or remap algorithms are satisfactory), and therefore doesn't itself lead to wasted hardware or needless head seeks. – agc Dec 14 '18 at 7:44

GParted doesn’t take any ext2/3/4 badblocks list into account; I checked this by creating an ext4 file system with a force bad block, then moving it using GParted. Running dumpe2fs -b on the moved partition shows the bad block at the same offset.

The result is 2, so the bad block ignored by the file system no longer corresponds to the real bad block on the medium. This means that the file system ignores a block it could safely use, and is liable to use the bad block it should avoid.

This does make sense, at some level. When GParted (or any other tool) moves a partition, it doesn’t use a file system-specific tool, it moves the container. This works in general because file system data is relative to its container; usually the file system data structures don’t need to be updated as a result of a move. However bad block lists describe features which don’t move with their container... Making GParted handle this would be quite complex: not only would it have to update the bad blocks list itself, it would also have to move data out of the way so that the bad block’s new position in the moved file system is unused.

  • Thanks for this useful answer! Calculating an offset doesn't seem that complex, at least for different partitions with the same file systems -- or perhaps I'm mistaken in supposing that resizing a whole drive partition down to a smaller one ending at the same spot already would require some file manipulation. OTOH, if the goal is minimal complexity, keeping the badblocks list after certain partition moves and copies seems needless. – agc Dec 14 '18 at 8:00

The bad blocks would not be removed, as I have seen a clone of a disk read bad blocks when written onto a new disk. The bad blocks themselves are marked. Those bad blocks then have to be rechecked and marked clean by a fixing tool e.g. fsck, ntfsfix or other. Those, however, are phantom bad blocks, not real badblocks. This however proves the idea that they must be fixed to be removed. Resizing shouldn't clear the marks and a full format of that partition should create new location markers for them. As for where it will point to after the operation I can't remember. This can however be tested, as agc said.

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.