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: Daniel P. Berrange
Subject: Re: [Qemu-block] [PATCH for-2.7 v2 05/17] raw-posix: Implement .bdrv_lockf
Date: Mon, 18 Apr 2016 10:34:30 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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