[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v10 14/16] file-posix: Implement im
From: |
Fam Zheng |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v10 14/16] file-posix: Implement image locking |
Date: |
Fri, 20 Jan 2017 09:56:28 +0800 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
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 <address@hidden>, 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
- [Qemu-block] [PATCH v10 08/16] iotests: 087: Don't attach test image twice, (continued)
- [Qemu-block] [PATCH v10 08/16] iotests: 087: Don't attach test image twice, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 09/16] iotests: 085: Avoid image locking conflict, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 10/16] iotests: 091: Quit QEMU before checking image, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 11/16] iotests: 172: Use separate images for multiple devices, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 12/16] tests: Use null-co:// instead of /dev/null as the dummy image, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 13/16] tests: Disable image lock in test-replication, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 14/16] file-posix: Implement image locking, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 15/16] qcow2: Force "no other writer" lock on bs->file, Fam Zheng, 2017/01/19
- [Qemu-block] [PATCH v10 16/16] tests: Add test-image-lock, Fam Zheng, 2017/01/19