15 hrs to compress 11GB Hard Drive
- Thread starter ivan308
- Start date
It is an issue with the latest beta and with the previous retail release and with the previous release candidate. It was a long job with earlier betas but it was not *that* bad.ivan308 said:
I think it all started since the first beta or release candidate when they said they included the "Compressor" product in Parallels Desktop.
Having a XP VM with a 60 GB expanding disk whose content is only about 11 to 12 GB, I can confirm your timings. This "compression" technology should be REMOVED from the product until it works. I have more than praises for Parallels Desktop and *love* this product. But this issue with compressing expanding disks makes me mad.
Newsociety
Bit poster
Thanks for posting this info!
Thought I was going crazy waiting for the compressor tool to work. I agree with Olivier, I too am a huge fan of this product but these wait times for compression are just uncceptable!
N
Thought I was going crazy waiting for the compressor tool to work. I agree with Olivier, I too am a huge fan of this product but these wait times for compression are just uncceptable!
N
Hugh Watkins
Forum Maven
how do you get such a big parallels image?
best to keep your data in shared folders
Hugh W
best to keep your data in shared folders
Hugh W
11 GB is not a big parallels image. Just install XP SP2, and Visual Studio 2005 and some other development or development-related tools, and you will very quickly get there. Any disk defragmenting tool or partition manager tool able (which are comparable complexity systems) are orders of magnitude quicker than Parallels compression.
Storing as much as possible through shared folders? Been there, tried that. Excellent solution for the typical word and excel documents. Building my typical project entirely stored on a shared folder (even with MSVC8 itself on the image) takes 40 min at least. The very same project when stored and built on the disk image itself takes 6 min and a half.
Except for horrible compression time about once a quarter, my VM size ranging from 11 to 20 GB is not a problem at all in everyday use and I get **excellent** performance from it.
Storing as much as possible through shared folders? Been there, tried that. Excellent solution for the typical word and excel documents. Building my typical project entirely stored on a shared folder (even with MSVC8 itself on the image) takes 40 min at least. The very same project when stored and built on the disk image itself takes 6 min and a half.
Except for horrible compression time about once a quarter, my VM size ranging from 11 to 20 GB is not a problem at all in everyday use and I get **excellent** performance from it.
Olivier said:
With build 3188, compressing an expanding 32Gb virtual image (actual file size 13Gb) down to the used 11Gb doesn't take more than 30 mn in the worst case here, on a 2Ghz MBP with 2Gb ram. The issue you are seeing may derive from other environmental factors, or may be due to issues in the latest betas. The official release works just fine.
Timings are better with the current released code. But you quoted a post of mine dating back in summer 2006: obviously the comment was based on beta status by *that* time. It is better today (o a point that it is useable), though still an impressively slow process for such a modest virtual HD size (around 11 to 13 GB).fpillet said:
hschneider
Pro
I can confirm this for the latest release built 3188 too. The compressor should not be removed, because it is the only way to shrink images. Better slow than none.
XP images can grow rather fast, if you have system restore points enabled while doing a lot of software installations. Disabling them can save a lot of space. I think there is no need for them, because a simple backup gives you much more control.
A good tool to examine which files and folders eat up the most can be found e.g. here: http://www.sixty-five.cc/sm/ BTW: The locked block holds the restore points. Just check out how much you could save without'em
About how to disable them see http://support.microsoft.com/kb/310405
XP images can grow rather fast, if you have system restore points enabled while doing a lot of software installations. Disabling them can save a lot of space. I think there is no need for them, because a simple backup gives you much more control.
A good tool to examine which files and folders eat up the most can be found e.g. here: http://www.sixty-five.cc/sm/ BTW: The locked block holds the restore points. Just check out how much you could save without'em
About how to disable them see http://support.microsoft.com/kb/310405
Last edited:
Of course, it shouldn't be removed. Again my sarcastic comment dates back to LAST SUMMER (2006). By that time the performance of the compressor tool was so abnormal... Today, it is slow, but certainly acceptable. I use it every 2 (or 3 months). It clearly don't have the 'bug' anymore which made it slow down more and more as its progress bar was getting close to complete.hschneider said:
I'm sure Parallels never considered removing it and certainly not as of today.
SLOW compression
FYI:
I just installed (today) the latest version of Parallels 3.0 (downloaded today, 6/12). I started a compression on a 16Gb XP disk that used to take about 30-40 minutes to compress. So far it's been running for 3.5 hours at 100% CPU usage on a MacBook Pro Core 2 Duo (measured where 200% is the "max"), and seems about 75% done. It's moving, but it's moving VERY slowly. This "compression" was the first thing I did after upgrading the HDD file.
What is so different between the 2.5 and 3.0 compression process???
Steve
UPDATE: What used to take 30-40 minutes now took just over 5 hours in Parallels 3.0 build 4128.
FYI:
I just installed (today) the latest version of Parallels 3.0 (downloaded today, 6/12). I started a compression on a 16Gb XP disk that used to take about 30-40 minutes to compress. So far it's been running for 3.5 hours at 100% CPU usage on a MacBook Pro Core 2 Duo (measured where 200% is the "max"), and seems about 75% done. It's moving, but it's moving VERY slowly. This "compression" was the first thing I did after upgrading the HDD file.
What is so different between the 2.5 and 3.0 compression process???
Steve
UPDATE: What used to take 30-40 minutes now took just over 5 hours in Parallels 3.0 build 4128.
Last edited:
gegervision
Hunter
I have a lot of windows development apps on my XP VM and it has now taken over 57 hours with build 4124, (yes I did say 57 hours) to compress my XP SP2 VM HDD. It's still going and currently at 75% complete. Can I safely cancel the compression without damaging the VM HDD? I want to make sure if I cancel before it completes and that I will not have to go through this entire process again just to get back where I currently am. I do have a backup of my VM before upgrading to 4124 so I can always revert back to if need be.
Thanks for any feedback.
Thanks for any feedback.
Last edited: