15 hrs to compress 11GB Hard Drive

Discussion in 'Parallels Desktop for Mac' started by ivan308, Aug 18, 2006.

  1. ivan308

    ivan308 Bit poster

    Messages:
    6
    I just ran the Compressor tool (Using the new Beta) and it took over 15hrs to compress an 11GB hard drive. I tried this both on a Macbook Pro and an iMac. Both have 2GB RAM.

    Is this normal ? Is this an issue with the new beta ?
     
  2. Olivier

    Olivier Forum Maven

    Messages:
    610
    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.

    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.

    :(
     
  3. Newsociety

    Newsociety Bit poster

    Messages:
    1
    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
     
  4. Hugh Watkins

    Hugh Watkins Forum Maven

    Messages:
    943
    how do you get such a big parallels image?

    best to keep your data in shared folders

    Hugh W
     
  5. Olivier

    Olivier Forum Maven

    Messages:
    610
    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.
     
  6. fpillet

    fpillet Junior Member

    Messages:
    14
    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.
     
  7. Olivier

    Olivier Forum Maven

    Messages:
    610
    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).
     
  8. hschneider

    hschneider Pro

    Messages:
    498
    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
     
    Last edited: May 29, 2007
  9. Olivier

    Olivier Forum Maven

    Messages:
    610
    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.
    I'm sure Parallels never considered removing it and certainly not as of today.
     
  10. sparker

    sparker Member

    Messages:
    66
    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. :mad: :confused: :(
     
    Last edited: Jun 12, 2007
  11. gegervision

    gegervision Hunter

    Messages:
    185
    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.
     
    Last edited: Jun 12, 2007

Share This Page