qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH VERSION 2] Disk image shared and exclusive locks.
Date: Mon, 07 Dec 2009 09:06:01 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Richard W.M. Jones wrote:
Here's a second go at this patch.  The only change is that we add a
second parameter (backinglock=none|shared|exclusive) which can be used
to control locking on the first level (only) of backing disk.

Dan Berrange convinced me there was a case to retain a distinct shared
locking type.

For any qemu instance which is going to use the "commit" command, I
would advise using: lock=exclusive,backinglock=exclusive.

For qemu instances which won't be using commit, I would advise:
lock=exclusive,backinglock=shared.

ETOOCOMPLEX

So the situation we're trying to support is:

1) something grabs exclusive (but why would it?)
2) we want to still be able to run things as shared

The alternative would be that we only provide lock=on|off. For GPFS-like shared filesystems (:-P) we would always use lock=off. It wouldn't protect us from a non-cluster aware writer.

I assume libguestfs is the user of exclusive. However, wouldn't it be reasonable for libguestfs to want to be able to mount the GPFS volume and manipulate it? Why wouldn't libguestfs want to also use lock=shared | lock=off in this case?

I think this is a knob you have to expose to your users. I think that also means that shared/exclusive is not so useful.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]