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

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Dec 07, 2009 at 08:15:51AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >>Better to stick with on/off.  That gives much easier to understand 
> >>semantics.
> >>    
> >
> >The 3rd invocation is not changing the backing file, so it is not causing
> >data corruption on the master file. Sure the 3rd OS instance will probably
> >crash & get confused because its backing file is changing under its feet
> >but as long as 'commit' isn't used, it is still safe.
> 
> The 3rd instance is getting data corruption.  The corruption is 
> transient because we're using -snapshot but if you change the scenario 
> to use a persistent cow overlay, then the corruption is permanent.
> 
> The semantics of shared/exclusive are non-obvious to anything but 
> someone who understands the implementation.
> 
> > 'commit' should 
> >require that the disk have been locked in exclusive  mode from the time
> >it started. It is not safe to merely let it upgrade the lock from
> >shared to exclusive at time of committing because of this exact scenario.
> >  
> I don't understand why it isn't safe to temporarily acquire a write lock 
> with commit.  Can you give an example of how it would cause corruption?

It is safe if you assume that no one else has tried to modify the disk
since you opened it, otherwise you'd be commiting changes against a 
base state which no longer exists.  The cluster scenario you outlined
in the parent message was the one I was thinking off.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|