aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc4xx.h
diff options
context:
space:
mode:
authoraliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>2008-12-02 20:14:05 +0000
committeraliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>2008-12-02 20:14:05 +0000
commite976c6a1e40ad74d616a186d3b48b0ad8f5eb970 (patch)
tree60e53f4d44261bd37a3dd39ff1a436f6c20617af /hw/ppc4xx.h
parent6db6c63826a4a2c06cb02bec2bfce3f506eacda8 (diff)
Change order of metadata update to prevent loosing guest data because of unexpected exit (Gleb Natapov)
Currently the order is this (during cow since it's the interesting case): 1. Decrement refcount of old clusters 2. Increment refcount for newly allocated clusters 3. Copy content of old sectors that will not be rewritten 4. Update L2 table with pointers to new clusters 5. Write guest data into new clusters (asynchronously) There are several problems with this order. The first one is that if qemu crashes (or killed or host reboots) after new clusters are linked into L2 table but before user data is written there, then on the next reboot guest will find neither old data nor new one in those sectors and this is not what gust expects even when journaling file system is in use. The other problem is that if qemu is killed between steps 1 and 4 then refcount of old cluster will be incorrect and may cause snapshot corruption. The patch change the order to be like this: 1. Increment refcount for newly allocated clusters 2. Write guest data into new clusters (asynchronously) 3. Copy content of old sectors that were not rewritten 4. Update L2 table with pointers to new clusters 5. Decrement refcount of old clusters Unexpected crash may cause cluster leakage, but guest data should be safe. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5861 c046a42c-6fe2-441c-8c8c-71466251a162
Diffstat (limited to 'hw/ppc4xx.h')
0 files changed, 0 insertions, 0 deletions