0

I am using SUSE Linux on a Virtual Machine through VMWare Workstation.

This morning, I zipped up a copy of the folder containing my VM (.vmx, .vmdk, .vmem, single snapshot and all) and sent it to my brother. The folder was initially 14gigs, and was compressed down to 10gigs. This process took nearly 45mins.

I continued doing some work, deleted maybe 200MB off the VM while cleaning it up (200GB is a generous estimate - I was writing code and refactored a bunch). I then zipped this up using 7-zip, with the same settings as before.

This time it took 15mins and compressed it down to 5gigs.

What possible reason is there for this? Same PC, same settings, assigned a high priority to 7zip in both cases. I assumed something was awry and waited fifteen mins just to verify the 5gig version wasn't broken. It wasn't, functioned perfectly.

Any ideas?

3
  • Did you use the same program (7zip) and the same compression algorithm, with the same settings both times? Did you have other CPU oder I/O intensive tasks running in the back ground? E.g: Compiler jobs, other compression jobs, vm's, other disk operations like copying files etc. ?
    – gilgwath
    Aug 20, 2014 at 11:23
  • @pardoxon Same program, same compression algorithm, same settings. CPU had a VMware image open both times, one of the times it was running a network transfer, the other time it was not - surely this wouldn't have such a dramatic impact though? I expected that it would output the same file regardless of what other programs are running on my local PC - is this not the case? Is the compression algorithm somehow altered by this? :) Aug 20, 2014 at 14:16
  • Hehe no but this would have at least accounted for the duration part of this quirk. But you are right, it does not account for the shrink in size.
    – gilgwath
    Aug 20, 2014 at 16:12

0

You must log in to answer this question.

Browse other questions tagged .