Snapshot Deletion Issues

[mboggy]

Can I delete a snapshot that is 28 GBs on a partition that is 6 GB without issue?

[socratis]

Read the following nice explanation about differencing disks and snapshots (which are based on the concept of differencing disks) and you'll get a pretty good idea how they work:

When a virtual disk is first created for a new virtual machine, it is considered as the base disk for the guest - data for the guest is read from and written to that disk image.

The differencing disk records changes sector-by-sector to the whole disk image, not changes to any file in the disk. VirtualBox does not know what file system is employed on the disk image and therefore can not access any individual file of/on the disk image; only the guest OS is aware of that information.

First SnapShot creates a differencing disk for read/write access while the base disk becomes read-only - as the guest modifies its data, the data is written to the differencing disk and the base disk is untouched.

Second SnapShot creates another, new, differencing disk for read/write access while the first differencing disk becomes read-only along with the base disk.

Subsequent SnapShots create additional differencing disks, with the preceding differencing disk joining the hierarchy (pecking order/chain) of read-only disks.

Keep in mind that access to/from the virtual disks is sector-by-sector, not file-by-file.

When the guest requests that a sector be read, the latest SnapShot is read first. If the sector is not found there (Sector-Not-Found is returned), the next SnapShot in the chain (youngest to oldest), until the base virtual disk is reached. Then the sector on/in the base virtual disk is either read or Sector-Not-Found is returned.

Now, you could post the "<Your_VM_name>.vbox" and tell us which snapshot you'd like to delete and we'd let you know about the consequences.

1. Right-click on the VM in the VirtualBox Manager. Select "Show in Finder/Explorer/Whatever".
2. ZIP the selected ".vbox" file and attach it in your response.

[mpack]

Can I delete a snapshot that is 28 GBs on a partition that is 6 GB without issue?

If I assume you actually mean that the host volume has 6GB free, then in that case I'll say that it's unlikely you'll be able to delete a 28GB snapshot without running out of disk space: deleting a snapshot involves merging the data into previous states, so it will need need a temporary working space potentially equal to the sum of the two states being merged (i.e. 28GB + <whatever>).

You should move the entire VM onto a drive with more free space. See Howto: Move a VM. Then I would delete all snapshots and never allow that feature to darken your door again.

Or, just clone the VM choosing "current state only", after selecting a new default machine folder in Preferences. However may cause activation issues with some guest OS's.

[socratis]

deleting a snapshot involves merging the data into previous states

Doesn't this happen in place??? I always thought it did, that's why snapshot merging was inherently dangerous.

[mpack]

As you know, I don't use snapshots, but I don't believe you would do it in place. It's simpler and safer to (a) create a new VDI and populate all the blocks, choosing as you go which file to take a block from. Only at the end, after successful creation of the merged VDI, would you (b) update the control structures to use it, then (c) delete the two input VDI files. Obviously the likely point of failure is during step (a), but it's relatively harmless: just issue an error message and discard the file.

Any other strategy seems to me to be ludicrously dangerous. The only "advantage" to doing it in place is that it requires slightly less disk space, but if space is that tight it would probably fail anyway, only catastrophically.

[socratis]

Test time! I love those...

• I have an OSX 10.12b2 VM. Base VDI: 10.83 GB^[1]. Snapshot: 2.1 MB (virgin).
• Update to OSX 10.12b3. Update size: 1.34 GB. Snapshot: 8.59 GB (after the update).
• Created a new snapshot. Total in chain, 3: Basic, Update, newly created.
• Merge Basic and Update by deleting Basic. Ended up with NewSnapshot (18.00 GB) and a (virgin) snapshot of 2.1 MB.
• Output of "while sleep 2 ; do df -lH ; done"^[2] was captured and made into a graph (wakes up the scientist in me ).
• The results were a little bit surprising, I'd say. First, the graph:

DeleteSnapshot.png (39.95 KiB) Viewed 1891 times

What I see is that starting with a total (10.83+8.59=) 19.42 GB, when merged I get a combined 18.00 GB. Expected.
What I also see is that at the end I was "richer" by about 1.4 GB (19.42-18). Expected as well.

What I don't understand is why it took only about 7 GB of extra space to do this. Where did that "7" come from?

---

[1]: GB are as Apple is reporting them, i.e. GB, not GiB.
[2]: Which means post every two seconds the amount of free space.

[mpack]

I'm not sure why you say the combined sizes are "expected". I certainly couldn't predict VDI size after a merge, knowing only the two pre merge sizes. It would critically depend on which blocks they had in common: if both snapshots have written to the same block, which is a likely occurrence I'd guess, then only one is kept. Any blocks which are unique to either A or B are kept, regardless.

Most I would say is that the merged size upper bound is the sum of the two input sizes, the lower bound is the size of the largest input VDI. If the VDI is heavily exercised (your test case isn't really a natural usage pattern) then I'd guess that the final VDI size will be closer to the lower bound than the upper.

[socratis]

"Expected," as in it didn't surprise me, not as in predicted. I highly doubt that anyone can predict what's overwritten and what gets written to a new sector (except maybe the heavy-duty filesystem optimization engineers, even that is stretching it).

There were 10.8 GB originally, plus 8.5 GB of update data (sum 19.3GB) and I got a combined 18 GB. Which is:
1) not more than the sum (that would be unexpected),
2) not the same as the original (that would be unexpected), and
3) a little less than their sum, which tells me that some of the sectors, but not all of them, were overwritten. Expected.

Now, for the temp space allocated, I would expect it to be the same as the end size of my final VDI (18GB), not 7GB, if it was a temporary copy of the merge action. The thing is that the temp was less than either the original, or the size of the update, which doesn't quite make sense.