From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1as5dw-0000UA-1D for qemu-devel@nongnu.org; Mon, 18 Apr 2016 05:39:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1as5dv-0002LQ-1e for qemu-devel@nongnu.org; Mon, 18 Apr 2016 05:38:55 -0400 References: <1460690887-32751-1-git-send-email-famz@redhat.com> <1460690887-32751-6-git-send-email-famz@redhat.com> <57123E3B.3070604@openvz.org> <20160418011244.GB18893@ad-mail.usersys.redhat.com> <20160418093430.GC19600@redhat.com> From: "Denis V. Lunev" Message-ID: <5714AB20.9070600@openvz.org> Date: Mon, 18 Apr 2016 12:38:40 +0300 MIME-Version: 1.0 In-Reply-To: <20160418093430.GC19600@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.7 v2 05/17] raw-posix: Implement .bdrv_lockf List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Fam Zheng Cc: qemu-devel@nongnu.org, Kevin Wolf , Max Reitz , Jeff Cody , Markus Armbruster , Eric Blake , John Snow , qemu-block@nongnu.org, pbonzini@redhat.com On 04/18/2016 12:34 PM, Daniel P. Berrange wrote: > On Mon, Apr 18, 2016 at 09:12:44AM +0800, Fam Zheng wrote: >> On Sat, 04/16 16:29, Denis V. Lunev wrote: >>> On 04/15/2016 06:27 AM, Fam Zheng wrote: >>>> virtlockd in libvirt locks the first byte, we lock byte 1 to avoid >>>> the intervene. >>>> >>>> Suggested-by: "Daniel P. Berrange" >>>> Signed-off-by: Fam Zheng >>>> --- >>>> block/raw-posix.c | 35 +++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 35 insertions(+) > >>>> @@ -1960,6 +1993,8 @@ BlockDriver bdrv_file = { >>>> .bdrv_detach_aio_context = raw_detach_aio_context, >>>> .bdrv_attach_aio_context = raw_attach_aio_context, >>>> + .bdrv_lockf = raw_lockf, >>>> + >>>> .create_opts = &raw_create_opts, >>>> }; >>> would it be better to use >>> >>> int flock(int fd, int operation); >>> >>> DESCRIPTION >>> Apply or remove an advisory lock on the open file specified by fd. >>> The >>> argument operation is one of the following: >>> >>> LOCK_SH Place a shared lock. More than one process may hold >>> a >>> shared lock for a given file at a given time. >>> >>> LOCK_EX Place an exclusive lock. Only one process may hold >>> an >>> exclusive lock for a given file at a given time. >>> >>> LOCK_UN Remove an existing lock held by this process. >>> >>> for this purpose? >>> >>> Sorry that missed this point in the initial review... >>> We will not intersect with libvirt for the case. >> As noted in the cover letter, flock() is nop on NFS mount points on Linux, so >> fcntl is safer. > Actually on Modern linux flock is implemented in terms of fcntl > on Linux. Flock does not do byte-range locking so by using > flock on NFS, IIUC you'll get a fcntl lock for the entire file > range on the server, which will clash with the fcntl lock that > virtlogd has acquired. On older linux flock is a no-op on NFS. > Other UNIX have varying degrees of usable for flock on NFS. So > in general fcntl is a better bet for NFS compatibility and will > not clash with libvirt. > > The only minor issue is that some versions of OCFS do not support > fcntl locks at all, only flock. > > Regards, > Daniel thank you for clarification this is not a bid deal at all :) This approach would work fine. Den