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

[Jamie Lokier <jamie@shareable.org>]

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).
> 
> Also if we only acquire the lock during the commit operation then
> we'll end up with disk corruption.  So we have to acquire the
> exclusive lock the whole time, for the image and the backing store.

It's ok to acquire the shared lock for the backing store, and then try
to upgrade it to exclusive when you do 'commit', then back to shared
afterwards.

Rather than disk corruption, what'll happen with both running is
'commit' will fail to get an exclusive lock because of the other
instance already having a shared lock, so you have to allow for the
possibility of 'commit' failing.  There won't be corruption anyway.

It's advisable to have an option to request exclusive lock for the
backing file at startup, so that you can commit to 'commit' succeeding.
Especially with -snapshot.

With -snapshot, often you mustn't take an exclusive lock on the
*grandparent* backing file, so the option to do exclusive lock up the
chain should not go all the way back.

-- Jamie