Am 11.09.2010 16:04, schrieb Anthony Liguori:
Image files have two types of data: immutable data that describes things like
image size, backing files, etc. and mutable data that includes offset and
reference count tables.
Today, image formats aggressively cache mutable data to improve performance. In
some cases, this happens before a guest even starts. When dealing with live
migration, since a file is open on two machines, the caching of meta data can
lead to data corruption.
This patch addresses this by introducing a mechanism to invalidate any cached
mutable data a block driver may have which is then used by the live migration
code.
NB, this still requires coherent shared storage. Addressing migration without
coherent shared storage (i.e. NFS) requires additional work.
Signed-off-by: Anthony Liguori<address@hidden>
diff --git a/block.c b/block.c
index ebbc376..cd2ee31 100644
--- a/block.c
+++ b/block.c
@@ -1453,6 +1453,22 @@ const char *bdrv_get_device_name(BlockDriverState *bs)
return bs->device_name;
}
+void bdrv_invalidate_cache(BlockDriverState *bs)
+{
+ if (bs->drv&& bs->drv->bdrv_invalidate_cache) {
+ bs->drv->bdrv_invalidate_cache(bs);
+ }
+}
There is a simple generic implementation:
drv = bs->drv;
drv->close(bs);
drv->open(bs, bs->open_flags);
Note that this only reopens e.g. the qcow2 layer, but not the image
file, which is bs->file.
This works for all simple case, that is, one format on top of one or
more protocols, where the protocols don't need invalidation. I think
this includes everything that is possible today. With -blockdev we might
need to revise this to include the lower layers, too. (But only
sometimes, because we don't want to reopen the file)
Kevin