Interpreting dd Input/Output error

Question

I tried to copy /dev/Storage/Storage (an LV under LVM) to an image file using a dd | pv | dd pipeline. dd reported an error, and I want to know whether dd finished copying my disk or stopped due to the error. I'm not sure since it gave me two different outputs: one with an error at the top and one without. I'd take a guess and say it didn't because between the two there's only an extra 0.1 seconds and no extra data, but I'm not sure if it did or not. /dev/Storage/Storage is a 1 TB disk (terabyte = 10¹² = 1000⁴) or 931.51 GiB (gibibyte = 2³⁰ = 1024³) or 1953513472 sectors. The filesystem on the disk is messed up and doesn't work properly.

$ sudo dd if=/dev/Storage/Storage | pv | dd of=Storage.img
dd: error reading ‘/dev/Storage/Storage’: Input/output error                   ]
1627672400+0 records ins] [   <=>                                              ]
1627672400+0 records out
833368268800 bytes (833 GB) copied, 75181 s, 11.1 MB/s
776GB 20:53:01 [10.6MB/s] [  <=>                                              ]
1627672400+0 records in
1627672400+0 records out
833368268800 bytes (833 GB) copied, 75181.1 s, 11.1 MB/s

Solution 1

• You are using the default 512 bytes dd block size. You would significantly improve performance by using a larger block size, say 128k or even 1m.

• There are two outputs because you are running two dd commands, the first one is the device reader and it shows an I/O error.

• You are likely using LVM given the device name you use: /dev/Storage/Storage. Are you sure this is the whole disk and not a subset? Use lvdisplay to figure out what is behind this device name.

Solution 2

Look in your kernel log messages (dmesg, or /var/log/kern.log) for more detailed messages from the SATA drivers, if it was a hardware error. Also useful: smartctl -x /dev/sda. If it was just an attempt to read past the end of a partition or something, that might also show up in the kernel log.

To get dd to keep going after an i/o error, to read the readable parts that follow the error, use

dd if=... of=... conv=noerror bs=128k   # it doesn't get any faster beyond about 128k, because of L2 cache size

(As mentioned in comments on the OP, ddrescue has this and more. conv=noerror was added to GNU dd after ddrescue existed, IIRC.)

If you want to resume where you left off, you can use the seek and skip options, with conv=notrunc.

---

If you really want to see how far along dd is, look at the file position of its stdin:

cat /proc/$(pidof dd)/fdinfo/0  # dd opens its infile as fd #0

(or ls -lh the size of the output file). Copying a whole hard-drive worth of data 2 extra times by piping it through something seems silly to me, like it will just make your computer a tiny bit slower than needed for the hours the copy will take.

Or at least do:

dd if=... conv=noerror bs=128k | pv > Storage.img

Solution 3

I was having the same problem and none of the tutorials or SO posts regarding dd specifically were helping out my particular form of this issue. After some digging, I found this question. This solution really worked well for me.

Here is an example for your use case:

$ sudo apt-get install gddrescue

$ sudo ddrescue /dev/Storage/Storage Storage.img | pv

The general form is:

$ sudo ddrescue <in_file> <out_file>

and then of course | pv if you want to pipe the stdout to the progress monitoring tool.

Comments

[Admin]

(1) Please show the command(s) that you typed to get this output.  (2) Do you know how big you disk is?  Please do not respond in comments; edit your question to provide the requested information.

[Admin]

One obvious question is whether your disk has 1627672400 sectors or not. Try blockdev --getsz /dev/whatever. If you copied the right number of sectors, then you are probably okay.

[Admin]

@user3188445 taking that as a no it didn't finish because it's 1953513472 sectors.

[Admin]

@Scott I updated my question but it's looking like it didn't finish...which means another 20+ hour copy.

[Admin]

Rather than using dd for this you might want to take a look at ddrescue. There are actually 2 programs by that name: 1) the original, which is normally named dd_rescue, and 2) a GNU program with the package name `gddrescue. The GNU program is generally better & far easier to use than the original one, although IIRC the original has a few extra features that are sometimes useful.

[Admin]

(cont) ddrescue has several advantages over dd for recovery work, especially from faulty hardware. It doesn't stop for mere read errors, and because ddrescue records its progress to a logfile, if it's interrupted for any reason it can resume recovery. If necessary, it can make multiple passes over a device to try to recover as much data as possible from a dying disk. The basic operation is similar to dd but I strongly advise reading the docs thoroughly before you attempt to use it.

[Admin]

@PM2Ring yes I'm familiar with ddrescue I chose dd because I don't need the functionality of ddrescue. The FS on the disk is a mess but that's due to a partitioning mistake on my part. The disk itself is completely fine. In fact the reason it read errored is because during the copy there was another accident on the disk while using some other software to work on it while dd was copying it and I think that's what caused it. The second time around it worked like a charm.

[Admin]

Ah, ok. I mostly mentioned ddrescue for its resumability, after reading your comment complaining about another 20+ hour copy. You can resume with dd, but you have to be very careful not to mess up the offset calculations or the image file will be rubbish. I'm glad you were able to recover successfully. Having a scrambled disk can be very unpleasant.

[Admin]

@PM2Ring Yea well now it's just a matter of fixing the FS on the disk. Although I don't know I'll be very successful with that. No one has responded to my question on here regarding ext4 superblock searching and restoring. I got some of my data back thanks to foremost but it's a mess to search through and I'm still missing some.

[Admin]

Any luck with testdisk?

[Admin]

@PM2Ring No. It found a bunch of ext4 filesystems but every time I opened them it would tell me there were no files found or it couldn't open it. So I have to find some other way.

[Admin]

@PM2Ring If you want to know my situation unix.stackexchange.com/q/223428/101019

[Scoopta]

/dev/Storage/Storage is an LV under LVM. Containing what's left of a mangled ext4 filesystem I'm currently working on recovering. I'll take the advice about bs on my second go round. I think I know why it errored the first time but I was hoping it finished. Thanks for pointing out the obvious which I clearly didn't see with the running two dd commands haha. Would I tell both dd commands to use that bs or only the one reading the disk?

[Scoopta]

Nvm...holy balls...1M bs for da win.

[Emmanuel]

Note that you can kill -USR1 the process PID to get the dd stats.

[Shruti]

You can also use the progress command (github.com/Xfennec/progress) which does automatically the same thing as the fdinfo-based solution.