From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46931)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jdillama@redhat.com>) id 1bASf3-0004lk-IH
	for qemu-devel@nongnu.org; Tue, 07 Jun 2016 21:52:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jdillama@redhat.com>) id 1bASex-0008FY-LW
	for qemu-devel@nongnu.org; Tue, 07 Jun 2016 21:52:00 -0400
Received: from mail-pf0-f174.google.com ([209.85.192.174]:35877)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jdillama@redhat.com>) id 1bASex-0008FO-Fm
	for qemu-devel@nongnu.org; Tue, 07 Jun 2016 21:51:55 -0400
Received: by mail-pf0-f174.google.com with SMTP id t190so9592387pfb.3
	for <qemu-devel@nongnu.org>; Tue, 07 Jun 2016 18:51:54 -0700 (PDT)
MIME-Version: 1.0
Reply-To: dillaman@redhat.com
In-Reply-To: <1464943756-14143-5-git-send-email-famz@redhat.com>
References: <1464943756-14143-1-git-send-email-famz@redhat.com>
	<1464943756-14143-5-git-send-email-famz@redhat.com>
Date: Tue, 7 Jun 2016 21:51:53 -0400
Message-ID: <CA+aFP1B0=ZGErk32rBo8NXM32RFthzKfvVn7P9gwMs3=M0dkZg@mail.gmail.com>
From: Jason Dillaman <jdillama@redhat.com>
Content-Type: text/plain; charset=UTF-8
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: Fam Zheng <famz@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 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.

-- 
Jason