dd does low-level copy and therefore pre-empts any other writing to the disk--including formatting. When you clone a disk you get the exact setup you had on the original.

You already know the "exact command line". I simply suggested using bs to specify the block size. "man dd" for all the gory details.

I don't know how long it should take--that is why I suggested the experiment. I don't have anything here that I can clone to, so I can't try it. I would suggest doing something else for a while--if its not done when you get tired of waiting, then start over.

The next time you start a long running dd, you might want to use pv to monitor its progress.

dd on a 40 gig drive takes a long time. Whenever I do something like that I do it overnight. Also if your drive is dying (which also might slow it down), I've found that dd_rescue is much better because it doesn't quit or trucate anything if an error in the disk occurs. dd_rescue has different syntax from dd.

It will also take longer if you are going from a drive that is on the same ide chain on the motherboard. In other words hda to hdb is slower than hda to hdc.

I played around with is a little and I noticed the higher the number for "bs=" the slower it goes. I just left the "bs=" off for the fastest time. I figured it should take about 26 hours for a 80Gig drive at the test rates I was getting. It's been about 20 hours and it's still going.

I didn't think about it at the time but I should have set the new drive as the primary drive on the secondary controller and maybe it would have been a little faster.

I used:

dd if=/dev/hda of=/dev/hdb conv=noerror

It's been running for about 24 hours and now I am getting:

dd: reading '/dev/hda': Input/output error
94665360+0 records in
94665360+0 records out

Will this eventually continue on with the copy or will it continue to loop on this error.?

If you are at a command line it means it choked and stopped.

However, since you used conv=noerror instead of conv=noerror,sync you may encounter unrecoverable problems on the new disk. Here is a page that might explain why http://www.mail-archive.com/forensic.../msg00090.html

Here is the relevant section from that page:
<SNIP from dd man>
noerror = Do not stop processing on an input error. When an input error
occurs, a diagnostic message shall be written on standard error,
followed by the current input and output block counts in the same format
as used at completion (see the STDERR section). If the sync conversion
is specified, the missing input shall be replaced with null bytes and
processed normally; otherwise, the input block shall be omitted from the
output.
</SNIP>

Your data is going to be truncated. If there a files located after the truncated section your probably going to have problems. Your file allocation table won't be able to find the files.

When using a bad disk dd_rescue really is the way to go. I know you're not going to like this but I"m going to recommend you start over..... I know, I know.... But at least you can be more sure of data integrity. And if you can put the second drive on the 2ndary ide chain that would help too.

dd_rescue does give a status so you won't be totally in the dark. Make sure you have dd_rescue on your system too. the syntax for it is easy

Possibly water under the bridge, but:
When you changed the block size, did you also change the count so that you were transferring the same total amount of data?

For example, these two commands will move the same amount of data:
dd if=/dev/hda of=/dev/hdb bs=1M count=100
and
dd if=/dev/hda of=/dev/hdb bs=10M count=10

And thanks to those who pointed out dd_rescue. (New one on me---it is not in my RHEL4 box, and also not in the latest Kubuntu. I did find it thru Synaptic)

I don't have a command prompt. It's still looping:
dd: reading '/dev/hda': Input/output error
94665360+0 records in
94665360+0 records out

I would assume the error is with hda since it it says "dd: reading '/dev/hda': Input/output error"

Should I just stop and try using dd_rescue.?

Where do I get dd_rescue.?

I saw this earlier and did not fully absorb it. Are you saying that it issued this message, but the drives are still running? If so, then--YES--it is time to stop and start over.
I got dd_rescue thru Synaptic on my Kubuntu system. Also, look here
I don't personally know anything about dd_rescue, but Google appears to know LOTS....

Well since you are this far into it just keep on going..... These errors will make your 26 hr figure longer, though EDIT: well pixellany disagrees. Really I think you should start over because of that and the trucated output from not having 'sync'
You may already have it. Are you using live cd like knoppix? Or something else? I know knoppix has it already. You can also get it from http://www.garloff.de/kurt/linux/ddrescue/ . If you have a system that uses apt or yum you can install it that way (yum install dd_rescue)

Also, I just recently discovered dd_rescue and have used on 2 drives in the last 2 months with very good results.

I was out for a few hours and it's still looping but the message has changed. The old message was:
dd: reading '/dev/hda': Input/output error
94665360+0 records in
94665360+0 records out

Now it says:
dd: reading '/dev/hda': Input/output error
111320584+0 records in
111320584+0 records out

So i guess it's working but slowly. But if it's an 80Gig drive why is it reading "111,320,584 records".? How many records on an 80Gig drive.?

I would say you are now at the 56 Gig mark.....

I believe 1 record is 512 bytes

Also it should be pointed out that your drive, if it is dying, has a limited lifetime left.... Everytime you have an error, the new drive is not getting anything coppied to it, thereby borking the file system. Not to sound all gloom and doom, but you may not have 2nd shot if you wait too long......

When dd reports the number of records, "record" is the same as "block". If you do not specify the block size (bs) it defaults to 512. Thus you are in fact getting close.

The fact that it is reporting errors does not bode well for winding up with a usable clone--keep your fingers crossed.