This is the first time I use the dd command. I execute:

dd if=/dev/sdb2 of=/mnt/sdc1/Hdd1.img bs=512 conv=noerror,sync

Where the sdb is the destroyed hdd (size: 500 GB). I copying the partition sdb2 into an image. I've done it 6(!!) days. the img size is about 640 GB and still counting (i.e: it hasn't finished yet...). 6 days it's printing the copied data details (which byte it's copied to where) and it's not stopping.

Is it normal? how is it possible that the img size is larger than the whole destroyed hdd size? and when it suppose to finishing?

  • 4
    /dev/sdc1/Hdd1.img is a very odd output path. – Michael Homer Feb 1 '16 at 6:56
  • 1
    The output should be the same size as the input, anyway, but something doesn't match up here. Are you sure that's the command you ran? What does ls -l /dev/sdc1/Hdd1.img say? You can edit your post. – Michael Homer Feb 1 '16 at 6:58
  • following up on @MichaelHomer's comment, you probably wanted dd if=/dev/sdb2 of=/root/HDD.img ? – David Dai Feb 1 '16 at 7:02
  • 1
    What they said. Your of should be a filename on a mounted device, eg /mnt/sdc1/Hdd1.img. BTW, if /dev/sdb2 is a partition on a faulty HD you should consider using ddrescue rather than plain dd. – PM 2Ring Feb 1 '16 at 7:24
  • 2
    My bad, I meant to write of=/mnt/sdc1/Hdd1.img. :) – Raviv Feb 1 '16 at 10:15

By doing the copy 512 bytes at a time you are doing lots and lots of reads and writes. About a trillion, actually, if you do the math. You've also asked for sync [EDIT: this is not oflag=sync so the next statement is invalid], which means to wait for each write to actually make it out to disk before that write can return. Let's say your disk is pretty speedy so each write takes 2ms.

500gb / 512 bytes * 2ms = 22.6 days.

Wow, trillions billions of milliseconds added up fast, didn't they?

[EDIT: while that was certainly a fun bit of math, it's not accurate since oflag=sync wasn't used. The delays are more likely due to repeatedly reading bad sectors and those associated timeouts. The below dd_rescue approach should help quite a bit. Using plain dd with a larger block size might help, but not as much since it can't adapt its read size and won't skip over massive damage.]

If you use a larger block size and/or skipped the sync it will run MUCH faster:

# dd if=/dev/sdb2 of=/sdb2-image.img bs=1024k

If you're concerned about read errors on the sdb2 image read, use dd_rescue with the -A option to write out a block of zeroes instead of skipping that write. Skipping blocks with errors entirely can lead to problems when certain filesystem structures appear at different offsets from the start than they were originally. It's better to just have some unexpected zeroes. For example:

# dd_rescue -A /dev/sdb2 /sdb2-image.img

This will start out reading large blocks of data at once and only reduces it when it starts hitting errors.

EDIT: to directly answer the question, as suggesed by Micheal Johnson, when using conv=noerror,sync on dd or -A on dd_rescue, your image will end up the exact same size as your source. This is because every read will generate an identically sized write. Some versions of dd may keep running long past the end of the device since they ignore the end-of-file "error" per your conv=noerror request. I don't think Linux does this, but it's something to watch out for if your image seems to be getting larger than the source.

|improve this answer|||||
  • 2
    Wow, 22 days?! guess I chose the wrong parameters... Thanks for your informative answer. I'll try your suggestion, but the question is - how large will be the block size in the case of using dd_rescue? and in the case of 500 GB hdd, how long is it expected to work? – Raviv Feb 1 '16 at 10:23
  • 2
    You seem to be confusing conv=sync with oflag=sync. The former just null-pads truncated input blocks, just like dd_rescue -A; the latter would force the output to use synchronized I/O as you describe. – Ilmari Karonen Feb 1 '16 at 11:04
  • 1
    In my maths, that would rather be 1 billion or milliard (10^9), not one trillion (10^12 or 10^18 depending where you live). On a non-failing drive, I'd expect those read/write calls to take in the order or micro-seconds rather than milli-seconds. Good point about using dd_rescue or ddrescue though. – Stéphane Chazelas Feb 1 '16 at 12:36
  • Google math made easy: 500gb/512b*2ms. And yes, it looks like it should have been 1 billion vs. 1 trillion. Good thing I let Google do the work for me, eh? 500gb/512b – Steve Bonds Feb 1 '16 at 14:53
  • As @Ilmari Karonen pointed out, I did get conv=sync confused with oflag=sync so my simple multiplication is invalid. Using such a tiny block size will still take a very long time, as you discovered. If the drive is badly damaged, a simple dd could keep hitting the drive for days or weeks, damaging it in the process. dd_rescue or ddrescue will get as much data off as quickly as possible without damaging the drive further. A healthy drive copy of 500GB could take an hour or less. A worst-case image could take the above month. An average-ish likely case... maybe 4-8 hours using dd_rescue. – Steve Bonds Feb 1 '16 at 15:05

The size of the image is the same as the size of the partition that you are creating the image from. You haven't said how big your partition is, but if it's, say, half of the hard drive's total capacity then your stated size is not unreasonable depending on the size of the hard drive. The important thing is that the partition where you are saving the image has at least as much free space as the size of the partition that you are imaging - if not then the operation will fail with a "no space left on device" error. Also if sdc is "destroyed" then saving the image onto sdc1 (as hinted by your image file path) is probably a bad idea - perhaps you could clarify what you mean by "destroyed"?

In any case, the answer by Steve Bonds explains why it's taking so long, but that wasn't the question that you asked.

|improve this answer|||||
  • 1. I haven't said the partition size to prove that in the worst case, of single-partition hdd, with the max size of 500GB, the result is still much more than the original size. 2. The place that the image is saved to is absolutely larger than the image (about 1TB free space). 3. "Destroyed" mean that it not working (I have dropped my laptop accidentally). 4. I guess that my question, after the great explanation of Steve Bonds, will be - what is effecient way (and easy to understand) to recover the data.... – Raviv Feb 6 '16 at 12:23
  • If you're trying to recover data, then you should investigate ddrescue. – Micheal Johnson Feb 6 '16 at 12:26

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.