DD not working--SUCCESS!

[Karl Larsen]

Mikkel L. Ellertson wrote:
> Jacques B. wrote:
>   
>> Doing a dd of a live, running system is a potential problem.  Your
>> system is in constant state of change.  Granted if you are doing
>> nothing else with the system at the time and booted in run level 3 you
>> minimize this impact.  But in an X Windows environment with applets
>> running in the background chances are something is always happening in
>> the back ground, some of which could cause writes to the hard drive
>> (especially where you mentioned you wanted Internet access to keep
>> writing things and such - lots of disk activity resulting from that).
>> Imagine when you start the copy and dd reads the partition
>> information, the superblock, and inode table near the beginning of the
>> drive and writes it to the new drive.  Part way through the process
>> writes take place on the source drive thereby potentially altering
>> superblock information, block groups, and inodes.
>>
>>     
> You are much better off doing this at run level 1 then run level 3.
> You can mount the file systems read-only and still function in run
> level 1. (I still prefer to use a live CD - the System Rescue CD is
> nice for this.)
>
>   
>> I haven't looked at file system stuff in about 6 months and I'm not
>> the primary resource for that topic so I'm not fluent enough to fully
>> explain the issues.  But I do know enough about it to know imaging a
>> live system could cause (and likely will cause) issues.
>>
>> It is far safer to boot from a live CD without either drives mounted
>> (only connected) and then dd from one to the other.
>>
>>
>> dd will use lots of CPU time.  There are a number of bottle necks in
>> the process - hard drive speed, motherboard/hard drive controller,
>> cables, available RAM, and no doubt a number of others.  The CPU is
>> not likely your bottle neck.  Chances are it's the reading & writing
>> to the hard drive.  So dd would not need 100% of CPU if it fills up
>> the RAM quicker than it can read/write.  How much CPU time dd uses
>> will vary from scenario to scenario (all factors noted previously and
>> many others being considered).  Running it off a live CD would impact
>> its performance seeing you are using some of the RAM for the live CD.
>> But the stability it affords you vs doing it on a live system is worth
>> it.
>>
>>     
> dd should not use lots of CPU time. The bottleneck is disk access
> speed. Depending on the drivers used, and some tweaking, the system
> may be spending a lot of time in the disk driver routines doing
> basically nothing.
>
> I would think the speed would be the same regardless of the amount
> of RAM, so booting off a live CD should not make dd any slower,
> unless you are really low. (1 meg of free RAM should be plenty.)
>
> I could be wrong, but I thought that dd read one block at a time,
> and wrote one block at a time, unless you use the options to tweak
> that. Even if the system buffers disk writes to the target drive, it
> is still going to be the write speed of the target drive that will
> be the problem. You may get some increase in speed if the source and
> target drives are on different IDE interfaces. (source on hda,
> target on hdc)
>
> In any case, dd is not the best tool for the job. Something like
> parted or g4l that understands file systems would be a better
> choice. Unless your file system is full, (90% or more) it is going
> to be much faster, as they only copy used blocks. (Doing recovery,
> or making an image of a cracked system/damaged disk is another story...)
>
> Mikkel
>   
    All I can talk to is my measurements. And when I was making my copy 
with dd, top told me my CPU was 70% used by dd :-)
That is a lot of cpu use and I think those suggesting the use of the 
Rescue disk I have this:
The Rescue disk does not have dd. It also lacks RAM and will NOT work. I 
was getting email and doing things with my computer while dd was sending 
it to the other Hard Drive.

It worked just fine.



-- 

	Karl F. Larsen, AKA K5DI
	Linux User
	#450462   http://counter.li.org.