From: Fam Zheng <famz@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org, rjones@redhat.com
Subject: Re: [Qemu-devel] [PATCH v10 14/16] file-posix: Implement image locking
Date: Fri, 20 Jan 2017 09:56:28 +0800 [thread overview]
Message-ID: <20170120015628.GA29561@lemon> (raw)
In-Reply-To: <20170119154900.GB16641@redhat.com>
On Thu, 01/19 15:49, Daniel P. Berrange wrote:
> On Thu, Jan 19, 2017 at 10:38:14PM +0800, Fam Zheng wrote:
> > This implements open flag sensible image locking for local file
> > and host device protocol.
> >
> > virtlockd in libvirt locks the first byte, so we start looking at the
> > file bytes from 1.
> >
> > Quoting what was proposed by Kevin Wolf <kwolf@redhat.com>, there are
> > four locking modes by combining two bits (BDRV_O_RDWR and
> > BDRV_O_SHARE_RW), and implemented by taking two locks:
> >
> > Lock bytes:
> >
> > * byte 1: I can't allow other processes to write to the image
> > * byte 2: I am writing to the image
> >
> > Lock modes:
> >
> > * shared writer (BDRV_O_RDWR | BDRV_O_SHARE_RW): Take shared lock on
> > byte 2. Test whether byte 1 is locked using an exclusive lock, and
> > fail if so.
> >
> > * exclusive writer (BDRV_O_RDWR only): Take shared lock on byte 2. Test
> > whether byte 1 is locked using an exclusive lock, and fail if so. Then
> > take shared lock on byte 1. I suppose this is racy, but we can
> > probably tolerate that.
> >
> > * reader that can tolerate writers (BDRV_O_SHARE_RW only): Don't do anything
> >
> > * reader that can't tolerate writers (neither bit is set): Take shared
> > lock on byte 1. Test whether byte 2 is locked, and fail if so.
>
> Ahh, using two bytes is an interesting technique for mapping the four
> different access methods onto the more limit fcntl lock semantics. We
> might want to copy this approach in libvirt too....
>
> > +/* Posix file locking bytes. Libvirt takes byte 0, so start from byte 1. */
> > +#define RAW_LOCK_BYTE_MIN 1
> > +#define RAW_LOCK_BYTE_NO_OTHER_WRITER 1
> > +#define RAW_LOCK_BYTE_WRITE 2
>
> ...would you mind if QEMU started from say byte 10, leaving the first 10
> reserved for libvirt uses. This lets libvirt have a continuous space for
> its own usage if we want to use more bytes
That's easy, will do it. (Actually the descriptions above are a bit stale
because exclusive writers now take two bytes exclusively and the lock testings
are done with F_OFD_GETLK so that RO readers can test against shared locks
without acquiring a write lock, which requires O_RDWR).
Fam
next prev parent reply other threads:[~2017-01-20 1:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 14:38 [Qemu-devel] [PATCH v10 00/16] block: Image locking series Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 01/16] osdep: Add qemu_lock_fd and qemu_unlock_fd Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 02/16] block: Define BDRV_O_SHARE_RW Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 03/16] qemu-io: Set "share-rw" flag together with read-only Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 04/16] qemu-img: Set "share-rw" flag in read-only commands Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 05/16] block: Set "share-rw" flag in drive-backup when sync=none Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 06/16] iotests: 055: Don't attach the drive to vm for drive-backup Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 07/16] iotests: 030: Read-only open image for getting map Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 08/16] iotests: 087: Don't attach test image twice Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 09/16] iotests: 085: Avoid image locking conflict Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 10/16] iotests: 091: Quit QEMU before checking image Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 11/16] iotests: 172: Use separate images for multiple devices Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 12/16] tests: Use null-co:// instead of /dev/null as the dummy image Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 13/16] tests: Disable image lock in test-replication Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 14/16] file-posix: Implement image locking Fam Zheng
2017-01-19 15:49 ` Daniel P. Berrange
2017-01-19 16:19 ` [Qemu-devel] [Qemu-block] " Eric Blake
2017-01-19 17:35 ` Richard W.M. Jones
2017-01-20 1:56 ` Fam Zheng [this message]
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 15/16] qcow2: Force "no other writer" lock on bs->file Fam Zheng
2017-01-19 14:38 ` [Qemu-devel] [PATCH v10 16/16] tests: Add test-image-lock Fam Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170120015628.GA29561@lemon \
--to=famz@redhat.com \
--cc=berrange@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.