[Comments inline, below] On 8 November 2012 10:34, John A. Wallace <[email protected]> wrote: > (snip) > ... if I understand you right, it sounds as though > deleting snapshots cannot result in my loosing the state I would be in as of > the most recent snapshot, regardless of which point in time I start with.
Correct. Deleting snapshots never affects the current state, and doesn't affect the state stored by other snapshots (including the last one that you want to keep). (In the past I have suggested that the dialogs that appear when you delete a snapshot say that the current state will not be affected.) Deleting snapshots DOES affect the internal differencing disks used to implement the snapshots, but that's mostly an internal technical detail. Mostly an internal detail *Except* for affecting how long it takes to delete a sequence of snapshots... > I mean, if I delete any of them, all I am doing is merging them in this > sort of way: > > 1+1+1+1=4 > Now if these represent snapshots taken in time from left to right, and if I > delete the first one, it would appear to me necessarily that it becomes > merged with the second one, like so: > > (1+1)+1+1=4 > Or I can represent it like this: > 2+1+1=4 Yes. Deleting a snapshot always merges its data (VDI) with the *following* VDI. Always merged with the following. > So now the next question becomes clearer, what happens if I were to delete > the middle one of these. I mean, would doing so cause it to become like > this: > > (2+1)+1=4 > Or would it become like this: > 2+(1+1)=4 2+(1+1)=4, deleting the 1 always merges its VDI with the following VDI. > Regardless of how it ended up happening, what would it matter one way or the > other? In terms of the end result, you shouldn't care. In terms of how *long* it takes to perform the merges required, the order matters. Imagine you are the storeman in a warehouse. You have 4 stacks of canned bake beans you need to merge into a single stack. (The stacks represent the differencing VDI files backing the snapshots.) The only operation (re-stacking) available is to merge adjacent stacks, AND you can only merge left-to-right. In what order do you merge the stacks? The end result will always be the same (one stack). If you start at the left-most stack, and keep doing that from left-to-right, you will double handle cans as you move them. A can in the left-most stack will be handled once when merged right into stack 2, then again when merged into stack 3, and again when merged into stack 4. If instead you start at stack 3 (merge it right to stack 4), then merge stack 2, then stack 1, you minimise can handling. Same end result (all cans in stack 4), but less handling. The same logic applies when deleting snapshots causes the differencing VDI files to be merged. These are the merge rules (AFAIK): - Deleting the earliest (top-most) snapshot merges the VDI for the following snapshot (or the VDI for the 'Current State') 'backwards' into the base VDI. - Deleting other-than the earliest (top-most) snapshot merges the VDI for that snapshot 'forwards' into the VDI for the following snapshot (or the VDI for the 'Current State'). With those in mind, if you want to delete a sequence of snapshots, it will be more efficient (in bit-handling terms) to follow these suggestions: - If the earliest (top) snapshot is one of those to be deleted, then delete it first. - Otherwise, delete the most-recent (bottom-most) snapshot of the sequence. - Repeat. -- Mark ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ VBox-users-community mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vbox-users-community _______________________________________________ Unsubscribe: mailto:[email protected]?subject=unsubscribe
