[BlankMan]

You've excluded the use of one of the very important features of dd_rescue which allows it to copy data faster and that is the use of the -b and -B parameters.

Although -B has a default of 512 which is what you want so leaving it out is ok (I'm not one that relies on default values and always includes them in the command line because a new release can change them while you're thinking they remain the same, hate surprises like that), but -b defaults to 16384 which is too small. Setting it to 2M utilizes the cache on most hard disk thus improving performance. Setting it higher then 2M, say 4M, caused problems in some instances so 2M is a pretty safe bet.

BTW Good job.

<Added>

P.S. I like log files too and you left that parameter out.

 

[BlankMan]

Originally posted by PortlandPaw
Thank you for the info especially on the -b parameter. Remember that I'm booting from a CD in a Windows box with an NTFS drive (I probably didn't mention that) -- how could I write to a log file under those conditions?

To /var or someplace that has room then gzip it and put it on a floppy before you reboot and its gone.

<Added>

I should mention, even though you are booted from a CD and maybe think you cannot write because a CD is read only, you are not running off the CD like you do when you normally boot off a disk in Windoze or Linux. You are actually running off a pseudo disk (for lack of a better term) that is actually a memory disk and acts, for all practical purposes like a real disk, except for the fact, Poof! Gone! when you reboot. If you knew this, excuse me.

 

[BlankMan]

If the intent of this is to be a HowTo you might want to add the -B and -b parameters to the OP. If you don't use the -b you are not getting the full advantage of using dd_rescue.

 

[BlankMan]

I noticed you put 4M in the example, did you use 4M and did it work? I mentioned that 2M was a safer bet, I had some segmentation fault problems with dd_rescue when attempting to use 4M.

Also, if the drive only has a 2M cache and you request a 4M read you're going to be waiting on the disk.

So all in all 2M is a better recommendation for general usage, power users that understand UNIX/Linux, dd_rescue, and know the size of the cache on the source and destination drives can adjust it as they see fit.

And I noticed you updated it in the 4th post and not the first, I know you reference the 4th post in the 1st but chances are people in a hurry may miss the difference(s).

 

[BlankMan]

Betcha didn't think HowTo's would be so much fun eh?

 

[BlankMan]

Why use dd?? In a dd_rescue thread? I'm appalled!

His dd_rescue command line clearly shows he's using a 2M buffer so I see no advantage reverting back to dd. Well, I can't see any reason do ever revert back to dd...

Oh and just so everyone is aware that hdparm command will only work if DMA support is gen'd into the kernel.

 

[BlankMan]

These tips came from SR712 and were shamelessly copied from the forum which cannot be named. It explains how to set DMA on the source and target drives and set 2M block size to optimize the speed of copy.

After you boot into Linux, before you run the dd command:

hdparm -d1 /dev/hda /dev/hdc

[If you have the drives as hda and hdc.]

Then, use dd command like this to enable 2M block sizes:

dd if=/dev/hda of=/dev/hdc bs=2M

...if your source drive is hda and your destination drive is hdc.

If you find this information isn't helpful, by all means, don't use it.

Well my only concern is that you're cutting and pasting this stuff without any explanation or background on the commands and people that are not UNIX/Linux savoy are going to use them and they may not work. That is not helpful to people to who UNIX/Linux is completely unfamiliar. Some expect to use these commands verbatim and expect them to work as described, that is not always the case.

Case in point, the hdparm command you posted may not work for reasons I already stated which are not fully inclusive.

Second, the dd command you posted has pitfalls, one of which is no status reporting of progress which was one of the key factors that dd_rescue has over dd because people couldn't tell if dd was really doing anything. And second, a much BIGGER pitfall is with the 2M blocking size in your posted dd command every time dd encounters a bad spot you could lose in the transfer up to that 2M instead of what dd_rescue does i.e. fall back to the 512 byte blocking factor so you only lose 512 bytes (one sector) verses 2M. This could be critical and render the target disk unbootable depending where this occurs. Of course a 512 byte loss could do that also but with the blocking factor being 2M in the dd command verses 512 bytes for dd_rescue's -B option you're increasing the chance of that happening 4000 to 1. Not good odds in my book, I'd never take those odds.

This blocking factor fall back along with the status reporting that dd_rescue does were two of the reasons I started using dd_rescue instead of dd and did all the testing and bought it and my results to this forum. Going back and suggesting dd be used again is a step backwards IMO, there's nothing that indicates dd will work where dd_rescue won't or vise versa. If dd_rescue hangs dd will most likely hang too and the hang is more then likely due to a hard disk that is having a major problem.

Pretty arrogant comment to make, then don't use them, when we're trying to help others especially for people that may not be technical and understand the difference between dd and dd_rescue.

 

[BlankMan]

I post only that which I believe to be helpful to people. If everybody here were to limit their posts to only that which they know to be 100% accurate and in language that 100% of the people could understand 100% of the time, it would be a very barren board, indeed.

I'm sorry if I've somehow offended your sensitivities or haven't risen to your level of quality. Makes me sorry I started this thread.

Well...

Now that I think more about it, that dd command may not work at all on a source disk that has sectors that cannot be read. Without conv=noerror dd will stop at the point it encounters the first read error, and without conv=sync dd won't pad the 2M block so it is a 2M block when it writes it. If it were to read 10K into the 2M block and have a problem it would write 10k, then when it read the next 2M it would put it on the target disk right after that last 10K and now you're skewing the data on the target disk by that loss of 1.99M and that could be across partitions because dd is a physical sector copy. I'm not 100% sure of this not ever having a chance to test it but that's the way the man pages read. The only thing I'm not sure of is where dd picks up the start for read of the next 2M block from the source disk, right after the sector it couldn't read or at what would have been the end of that last 2M read block. If it's the end of the 2M read block, that's when things would get screwed up. Next time I have a failed disk I'm going to explore this so I know once and for all. Course that wouldn't really happen anyway because you don't have the conv=noerror so it would stop.

That dd command will only work on a source disk that does not have any read problems, which is an oxy moron because in most cases there would be no need to dd it in the first place. So, without conv=noerror,sync that dd command is useless in attempting to copy a source disk that has read problems.

So, how is a command that will not work on a failing disk helpful? But I should just shutup and not use it....

Makes me sorry I started this thread.

Of that you shouldn't be. It's nice to have this info in a place where people can find it and of that you have done a good job. I was just concerned that someone would jump to the end of the thread and think that that dd command was now the command in fashion. Nothing personal. You did what I didn't have the time to do and that was to do this thread as a HowTo and IMO that was GREAT!

 

[BlankMan]

WoW! This thread still lives. I am truly amazed.