[sclug] dd pain

[Roland Turner]

On Mon, May 19, 2003 at 09:14:40AM +0100, pieter claassen wrote:

> 1. It takes either very long or not to copy. These disks as all 40GB and
> the inconsistency bug me.

I've noticed this too. I've not needed to do this often enough to
bother getting to the bottom of it.

> 2. When I start the dd, I can normally see kswapd getting very active.
> Even if I boot the machine in single user mode with no X.
> 
> Here are my questions:
> 1. Can anybody think of a practical way to see how dd is doing in terms
> of progress. Unfortunately it currently only tells me on completion that
> all is fine or not.

Unhelpfully, I can tell you how to do it on most UNIXy OSs _except_
Linux; lsof tries to show you the offset that a given file descriptor
is at in a given file, however as of the /proc-based lsof that
came in some time ago, it is unable to reliably get at offset
information on Linux. You can force it to try (the -o option),
but if the test fails on one of its own files, it won't even
bother to try with other files.

More in lsof's FAQ[1] 10.2.1

> 2. Why is kswapd going even if there is no swap space mounted?

Speculation: there is no kpaged so perhaps the kernel uses the same
thread to control both paging and swapping. During bulk-I/O
(e.g. your multi-gigabyte dd), the kernel is likely to be paging
(reading and writing disk blocks) heavily.

> 3. Can anybody think of a faster more optimised and safer way to do
> this? I find that sometimes I stare for minutes at the screen to make

I suspect that dd really is the fastest way to do a full image
copy. An important optimisation may be to use something which
skips unused blocks (dump/restore? but watch that you dump the
filesystem R/O :-)).

> sure that I get the "if" and "of" right, but one slip and I will be a
> very sad person!

Safer? Don't know, I've never gotten it wrong yet. Ghost perhaps?

- Raz

1: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/FAQ