Computer slowdown when deleting snapshot

[vberic]

I'm curious about this: I'm deleting snapshots. The "last" one (top of the tree) is taking about 10 minutes.
What's curious is this: as VB is removing a snapshot (doing it "merge" thing), my entire computer slows way, way down (Win7 64bit, 4GB RAM, Pentium Dual-Core CPU T4300 @ 2.10GHz each). Yet the Task Manager performance monitor only shows between 5 and 15% usage. That last fact doesn't seem to fit with the computer slowing down so much.

Does anyone know the explanation?

[uli100]

I guess the slow down is caused by disk io.

Best regards, Uli.

[golimar]

It is definitely a I/O bottleneck. Optimizing this shouldn't be difficult. It looks like it has to read a lot of data and then write it again, both using the same disk. This could be done, for example:
- Instead of lots of smaller read and write operations, it should read a large amount of data into memory, then write it, then read again and so on (some users woudn't have much memory available so the size of this buffer could be a configurable option in Virtualbox)
- Using a different physical disk to store the temporary data and then writing it back to the primary disk (in case there is more than one physical disk in the computer)

[noteirak]

Yes, merging snapshots is basically going full usage on the disk, using all the available IO. You are basically merging 2 files together, usually of several GB, so lots of read/write there...

- Instead of lots of smaller read and write operations, it should read a large amount of data into memory, then write it, then read again and so on (some users woudn't have much memory available so the size of this buffer could be a configurable option in Virtualbox)

This won't do any good, the bottleneck is still the disk, you still have to read and write in sequence, and keep changing sectors on which you read and write. This is basically the worse you can do on a disk, perf wise.
Sadly, there isn't anything you can do on that bit.

- Using a different physical disk to store the temporary data and then writing it back to the primary disk (in case there is more than one physical disk in the computer)

How could Virtualbox decide which disk is acceptable to use space? What about permissions? What about another application need the IOPS of that disk? Sounds very very unsafe to me.
That bit should be handled by the user/sysadmin IF you can actually make a case for using snapshots that would spawn over GBs in the first place...

[mpack]

In any case this would be a non-issue for experienced users, who avoid the problem by avoiding snapshots.

[golimar]

Yes, merging snapshots is basically going full usage on the disk, using all the available IO. You are basically merging 2 files together, usually of several GB, so lots of read/write there...

- Instead of lots of smaller read and write operations, it should read a large amount of data into memory, then write it, then read again and so on (some users woudn't have much memory available so the size of this buffer could be a configurable option in Virtualbox)

This won't do any good, the bottleneck is still the disk, you still have to read and write in sequence, and keep changing sectors on which you read and write. This is basically the worse you can do on a disk, perf wise.
Sadly, there isn't anything you can do on that bit.

You have to change sectors much more if the disk head has to change too frequently from the place where it is reading, to the place where it is writing. The amount of data read and written will be the same, but in a less "fragmented" way. It's like doing few trips with a truck instead of a lot of trips with a car.

- Using a different physical disk to store the temporary data and then writing it back to the primary disk (in case there is more than one physical disk in the computer)

How could Virtualbox decide which disk is acceptable to use space? What about permissions? What about another application need the IOPS of that disk? Sounds very very unsafe to me.
That bit should be handled by the user/sysadmin IF you can actually make a case for using snapshots that would spawn over GBs in the first place...

True, the user should be the one choosing what disk to use for this. It's like when I'm uncompressing a big ZIP archive... I choose not to do it on the same place where the ZIP file lies, but instead I choose the other one for it

[mpack]

Golden rule: don't give the user the rope to hang himself with, at least not unless there's a correspondingly huge upside.

[golimar]

Sure , this shouldn't be active by default in case it's implemented.
The upside is actually huge. It takes a lot of time, puts the disk in a lot of stress, the computer is almost unusable during this process, and probably creates fragmentation. Of course, this only applies in cases when creating and deleting snapshots can't be avoided.