Changes between Version 5 and Version 6 of VDEchp

Timestamp:

10/04/11 00:52:31 (13 years ago)

Author:

lvpeng

Comment:

--

VDEchp

@@ -13 +13 @@
 the agent’s memory, and reset all pages to read-only again. Therefore, each checkpoint consists of only the pages which are updated within that checkpoint interval. And, since each checkpoint interval is very small, the number of updated pages in this interval is small as well, so it is unnecessary to assign large memory to each VDEchp agent.
 
-== Two Execution Cases Under VDEchp ==
+== Different Execution Cases Under VDEchp ==
 In the VDEchp design, for each VM, the state of its stablecopy is always one checkpoint interval behind the current VM’s state except the initial state. This means that, when a new checkpoint is generated, it is not copied to the stable-copy immediately. Instead, the last checkpoint will be copied to the stable-copy. The reason is that, there is latency between when an error occurs and when the failure caused by this error is detected.
 
@@ -33 +33 @@
 checkpoint request, each VM checks the latest recorded in-disk stable-copy (not the in-memory checkpoint), marks this stablecopy as part of the global checkpoint, and sends a “success” acknowledgement back to the Initiator. The algorithm terminates when the Initiator receives the acknowledgements from all the VMs. For example, if the Initiator sends a request (marked as rn) to checkpoint the entire VDE, a VM named VM1 in the VDE will record a stable-copy named “vm1 global rn”. All of the table-copies from each VM compose a globally consistent checkpoint for the entire VDE. Besides, if the
 VDEchp Initiator sends the checkpoint request at a userspecified frequency, the correct state of the entire VDE is recorded periodically.
+
+== Evaluation Results ==
+=== Downtime Evaluation for Solo VM ===