[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help using "dd" command!

From: Pádraig Brady
Subject: Re: Help using "dd" command!
Date: Sun, 14 Sep 2014 11:35:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 09/14/2014 05:49 AM, Ricardo Ramos wrote:
> Hello, I'm making a paper about disk image aquisition software and I need a
> little help from someone more experienced.
> I used 2 programs to clone a disk on a GNU/Linux machine (Ubuntu), they are
> "dd" and "DdRescue", and I used 3 different HDD, 120GB, 160GB and 500GB.
> I captured the behaviour of the commands using the program pidstat, and the
> reports showed that the programs had the same CPU usage patterns, but on
> the other hand each HDD showed a different pattern.
> [image: Imagem intercalada 1]
> Percentage of CPU cores suing dd on the 120GB HDD.
> [image: Imagem intercalada 2]
> Percentage of CPU cores suing dd on the 160GB HDD.
> [image: Imagem intercalada 3]
> Percentage of CPU cores suing Ddrescue on the 120GB HDD.
> [image: Imagem intercalada 4]
> Percentage of CPU cores suing Ddrescue on the 120GB HDD.
> Has you can see, it looks like it's a similar pattern, could anyone explain
> to me one or both of the work so that I can find out why are they using
> almost the same percentage of CPU cores and exactly the same cores.
> Thank you.
> PS: Sorry for the bad english, I'm a portuguese speaker.

This will probably be an I/O bound operation.
I.E. the CPU will be waiting for the storage subsystem.
You can make the I/O more efficient by adjusting the
amount of work done at a time using the dd bs parameter.
I've not looked at ddrescue but given its use case
I would expect it to have a dynamic block size that
would start out large for efficiency, and reduce in the presence
of read errors to minimize data loss.

Assuming no errors, you can get dd to behave efficiently
with a block size of say bs=2M

Also I've see bad interaction with the Linux page cache
especially for slow devices, so you might get improved
resource usage by avoiding that with iflag=direct oflag=direct


reply via email to

[Prev in Thread] Current Thread [Next in Thread]