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

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/10/2011 10:50 AM, Juan Quintela wrote:
> Kevin Wolf<kwolf@redhat.com>  wrote:
>
>>> What I took from the feedback was that Kevin wanted to defer open until the
>>> device model started.  That eliminates the need to reopen or have a invalidation
>>> callback.
>>>
>>> I think it would be good for Kevin to comment here though because I might have
>>> misunderstood his feedback.
>>
>> Your approach was to delay reads, but still keep the image open. I think
>> I worried that we might have additional reads somewhere that we don't
>> know about, and this is why I proposed delaying the open as well, so
>> that any read would always fail.
>>
>> I believe just reopening the image is (almost?) as good and it's way
>> easier to do, so I would be inclined to do that for 1.0.
>>
>> I'm not 100% sure about cases like iscsi, where reopening doesn't help.
>> I think delaying the open doesn't help there either if you migrate from
>> A to B and then back from B to A, you could still get old data. So for
>> iscsi probably cache=none remains the only safe choice, whatever we do.
>
> iSCSI and NFS only works with cache=none.  Even on NFS with close+open,
> we have troubles if anything else has the file opened (think libvirt,
> guestfs, whatever).

Reopening with iSCSI is strictly an issue with the in-kernel initiator, right? 
libiscsi should be safe with a delayed open I would imagine.

Regards,

Anthony Liguori

   I really think that anynthing different of
> cache=none from iSCSI or NFS is just betting (and yes, it took a while
> for Christoph to convince me, I was trying to a "poor man" distributed
> lock manager, and as everybody knows, it is a _difficult_ problem to
> solve.).
>
> Later, Juan.
>