I dd_rescue'd a hard drive, and I know where the bad blocks are. I still have the drive with me, so I can get any information needed from SMART or fdisk.

I would like to know if it is possible to see, physically, where these bad blocks are located. I've heard about sectors, tracks, cylinders (at least in old disks), but I don't know precisely how a disk is organized, or the maths involved in mapping a block to a physical sector. I'm sure this will be a good place to start, and I'll search for it as soon as I can, but since this is a situation I have now, I'm asking the question in advance so anyone may be able to help me sooner.

Ideally, I would have the (literal) image of a circular disk, and I would be able to pinpoint where, in the disk, is, let's say, block #1000.

Is it doable? Probably not in disks with wear-leveling techniques, but at least on a desktop hard drive, such as a Western Digital Caviar Green, which is the one I'm looking at, with over 40k bad blocks.

It is an academic question. This disk will obviously no longer be trusted, but I would like to be able to see if a physical pattern exists.

  • What does this question have to do with system administration?
    – kasperd
    Commented Oct 9, 2014 at 8:55
  • My idea was that hardware-related questions such as this one would also be fit for Server Fault. It is on the operation of system administration that this kind of question arises. I don't find it very different from one about SMART values, apart from the fact that I wanted to understand how the problems actually appear, at a physical level. However, I do see that I am failing the "not about... Anything in a home or development environment". My apologies for this fact; maybe moving to Super User is more appropriate? Commented Oct 10, 2014 at 2:00

1 Answer 1


This really isn't feasible with modern disks.

In the old days disks were essentially dumb devices (simplifying, but stick with me). The system would request data from a particular Cylinder (physically a ring on the disk), Head (2 heads per platter), and Sector (each ring had sector numbered from 1 to whatever). The controller told the disk to move to such and such CHS location and read or write the data. You knew that cylinder 0 was near the edge of the disk, and the highest cylinder was at the root. Really ancient disks had a physical mark where sector 1 was located in each cylinder, so you could open a drive and almost see data locations.

Today's disks have permanent formattings that include address information, true physical addresses, not the logical ones presented to the controller. When a disk is asked to move the head to Large Block Address (LBA) 0, that is mapped to a physical sector (probably the actual first sector, or near there, unless it's been remapped). But the disk predicts where that sector will be based on guess algorithm. It then waits for the next sector to fly under the head, reading the address - if it guessed wrong it adjusts, if just guessed right then it reads/writes the sector. This guessing process is necessary because the disk physically expands as it heats up, causing the sector to be in a different place when the disk is warm or cold. Also, there's isn't a consistent number of sectors in each cylinder. The older CHS disks had physically different size sectors because of the addressing system. Modern disks have consistent size sectors because they're just numbered from 0 to whatever sequentially.

To compound your question, as a disk detects sectors that may or actually have problems, it remaps them silently (SMART shows, but it's not an error to the host OS until it's unreadable - or SCSI disks can be told to notify the host OS). So the logical LBAs you see might not correspond to the physical addresses internal to the drive.

  • Thanks for your answer, it makes sense. That means that I am unlikely to ever understand what happened to the disk, since 40k bad blocks on a drive that is less than 3 years old seem to be quite a lot. On a different note, what happened in this comment section? Commented Oct 10, 2014 at 2:03

You must log in to answer this question.

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