Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions

[Kevin Wolf <kwolf@redhat.com>]

Am 12.11.2011 11:25, schrieb Avi Kivity:
> On 11/11/2011 12:15 PM, Kevin Wolf wrote:
>> Am 10.11.2011 22:30, schrieb Anthony Liguori:
>>> Live migration with qcow2 or any other image format is just not going to work 
>>> right now even with proper clustered storage.  I think doing a block level flush 
>>> cache interface and letting block devices decide how to do it is the best approach.
>>
>> I would really prefer reusing the existing open/close code. It means
>> less (duplicated) code, is existing code that is well tested and doesn't
>> make migration much of a special case.
>>
>> If you want to avoid reopening the file on the OS level, we can reopen
>> only the topmost layer (i.e. the format, but not the protocol) for now
>> and in 1.1 we can use bdrv_reopen().
> 
> Intuitively I dislike _reopen style interfaces.  If the second open
> yields different results from the first, does it invalidate any
> computations in between?

Not sure what results and what computation you mean, but let me clarify
a bit about bdrv_reopen:

The main purpose of bdrv_reopen() is to change flags, for example toggle
O_SYNC during runtime in order to allow the guest to toggle WCE. This
doesn't necessarily mean a close()/open() sequence if there are other
means to change the flags, like fcntl() (or even using other protocols
than files).

The idea here was to extend this to invalidate all caches if some
specific flag is set. As you don't change any other flag, this will
usually not be a reopen on a lower level.

If we need to use open() though, and it fails (this is really the only
"different" result that comes to mind) then bdrv_reopen() would fail and
the old fd would stay in use. Migration would have to fail, but I don't
think this case is ever needed for reopening after migration.

> What's wrong with just delaying the open?

Nothing, except that with today's code it's harder to do.

Kevin