Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just now after waiting about 33 hours I finished restoring hard disk resided on the LVM partition from previosly created zipped dump

Here is its status:

gzip -dc /servdata/backup/trex/ | dd of=/dev/trex/
134217728+0 records in
134217728+0 records out
68719476736 bytes (69 GB) copied, 120513 s, 570 kB/s

How I can improve copying speed (570 kB/s is very slow). May be I need to use another tool for working with LVM?

Thanks a lot.

share|improve this question

migrated from Nov 6 '12 at 14:29

This question came from our site for professional and enthusiast programmers.

It could be that gzip is slowing down the thing. – Basile Starynkevitch Nov 6 '12 at 13:25
If you have a really weak CPU: Yes, gzip could slow things down. But I suspect most of those 33 hours are not used on decompressing 69GB. The overhead of 134217728 (512 bytes sized) transactions is a much more likely cause. – Hennes Nov 6 '12 at 14:53

The default blocksize of dd is 512 bytes read or written. You can increase it to 1 megabyte for example, to improve writing speed:

$ gzip -dc /servdata/backup/trex/ | dd bs=1M of=/dev/trex/

See man dd for further info.

share|improve this answer
The blocksize is definitely the issue here. – ypnos Nov 6 '12 at 14:38
Is dd needed at all in this case? I recall doing simple zcat to a filesystem (e.g. gzip -dc /servdata/backup/trex/ > /dev/trex/ – Hennes Nov 6 '12 at 14:55
I should work without dd, but I don't know how fast or slow it would be. – Olaf Dietsche Nov 6 '12 at 17:36

You must log in to answer this question.