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 <aligu...@us.ibm.com>
>
> 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
