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.
