Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.

[Anthony Liguori <anthony@codemonkey.ws>]

Richard W.M. Jones wrote:
> On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote:
>   
>> I think I made my point poorly.  Consider the following:
>>
>> qemu-img create -f raw base.img 10G
>> qemu-img create -f qcow2 -b base.img cow1.img
>> qemu-img create -f qcow2 -b base.img cow2.img
>>
>> qemu -drive file=cow1.img,lock=exclusive
>> qemu -drive file=cow2.img,lock=exclusive
>>
>> With the current patch, the second command will fail and it's impossible  
>> to invoke correctly.  That's because flags are passed down to backing  
>> devices directly.
>>     
>
> Isn't it correct that the second command fails?  Although the base
> image is mostly used read-only, if the user does the "commit" command
> in the monitor then the backing image is overwritten.  (That's my
> understanding of the documentation anyway - I've never actually used
> this feature of qcow2).
>   

That's a use-case that needs to be thought through.  Maybe commit should 
attempt to force the lower level to acquire a write lock first?

The above use-case is extremely common so it's something that's worth 
supporting.

> Also if we only acquire the lock during the commit operation then
> we'll end up with disk corruption.

Why do we end up with disk corruption?

If someone else has the backing file open with a read lock, we won't be 
able to acquire the write lock.  Once we've acquired the write lock, no 
one can acquire the read lock.  Once we've released the write lock 
(after an fsync of  course), we won't touch it again.

Regards,

Anthony Liguori