Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Just now after waiting about 33 hours I finished restoring hard disk dev.pm.m3 resided on the LVM partition from previosly created zipped dump 5_dev.pm.m3_2012-11-03.gz.

Here is its status:

gzip -dc /servdata/backup/trex/5_dev.pm.m3_2012-11-03.gz | dd of=/dev/trex/dev.pm.m3
.................
.................
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 stackoverflow.com 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
add comment

1 Answer

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/5_dev.pm.m3_2012-11-03.gz | dd bs=1M of=/dev/trex/dev.pm.m3

See man dd for further info.

share|improve this answer
2  
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/5_dev.pm.m3_2012-11-03.gz > /dev/trex/dev.pm.m3) –  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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.