qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH for-2.7 v2 05/17] raw-posix: Implement .bdrv_loc


From: Denis V. Lunev
Subject: Re: [Qemu-block] [PATCH for-2.7 v2 05/17] raw-posix: Implement .bdrv_lockf
Date: Mon, 18 Apr 2016 12:38:40 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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" <address@hidden>
Signed-off-by: Fam Zheng <address@hidden>
---
  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



reply via email to

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