From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55320)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1bATV1-00039L-Hp
	for qemu-devel@nongnu.org; Tue, 07 Jun 2016 22:45:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1bATUz-00037I-KI
	for qemu-devel@nongnu.org; Tue, 07 Jun 2016 22:45:42 -0400
Date: Wed, 8 Jun 2016 10:45:29 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20160608024529.GA12578@ad.usersys.redhat.com>
References: <1464943756-14143-1-git-send-email-famz@redhat.com>
	<1464943756-14143-5-git-send-email-famz@redhat.com>
	<CA+aFP1B0=ZGErk32rBo8NXM32RFthzKfvVn7P9gwMs3=M0dkZg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+aFP1B0=ZGErk32rBo8NXM32RFthzKfvVn7P9gwMs3=M0dkZg@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH v6 04/22] block: Introduce image file
 locking
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: dillaman@redhat.com
Cc: qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org, rjones@redhat.com, John Snow <jsnow@redhat.com>, Jeff Cody <jcody@redhat.com>, Markus Armbruster <armbru@redhat.com>, Max Reitz <mreitz@redhat.com>, stefanha@redhat.com, den@openvz.org, Paolo Bonzini <pbonzini@redhat.com>

On Tue, 06/07 21:51, Jason Dillaman wrote:
> On Fri, Jun 3, 2016 at 4:48 AM, Fam Zheng <famz@redhat.com> wrote:
> > +typedef enum {
> > +    /* The values are ordered so that lower number implies higher restriction.
> > +     * Starting from 1 to make 0 an invalid value.
> > +     * */
> > +    BDRV_LOCKF_EXCLUSIVE = 1,
> > +    BDRV_LOCKF_SHARED,
> > +    BDRV_LOCKF_UNLOCK,
> > +} BdrvLockfCmd;
> > +
> 
> We started to talk about new APIs in librbd to support this feature
> where we don't need to worry about admin action should QEMU crash
> while holding the lock.
> 
> Any chance for separating the UNLOCK enum into the exclusive vs shared
> case? We could do some magic in the rbd block driver to guess how it
> was locked but it seems like it would be cleaner (at least for us) to
> explicitly call out what type of unlock you are requesting since it
> will involve different API methods.

This should be possible but I'm not sure I fully understand the rationale
behind it. The server side who implements the lock and keeps track of states
should have the lock type information already, why is it necessary for the
client to be explicit? It doesn't sound necessary to me at all from an
interface point of view. Can you elaborate more on the API methods that need
this?

Fam