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 -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
