From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, mreitz@redhat.com,
eblake@redhat.com, den@openvz.org,
Kirill Tkhai <ktkhai@virtuozzo.com>
Subject: Re: [PATCH RFC] docs: document file-posix locking protocol
Date: Tue, 22 Jun 2021 14:14:10 +0300 [thread overview]
Message-ID: <bc400a16-3df4-30fd-9c6d-3cd5bbd00e4a@virtuozzo.com> (raw)
In-Reply-To: <69357fc0-7c67-ace5-867b-135b6abc69bd@virtuozzo.com>
Ping. Any thoughts?
24.05.2021 17:40, Vladimir Sementsov-Ogievskiy wrote:
> Ping.
>
> We need to synchronize access to qcow2 images between Qemu and our internal program. For this solution to be reliable, the locking protocol should be documented at least..
>
> 22.03.2021 21:27, Vladimir Sementsov-Ogievskiy wrote:
>> Let's document how we use file locks in file-posix driver, to allow
>> external programs to "communicate" in this way with Qemu.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---
>>
>> Hi all!
>>
>> We need to access disk images from non-Qemu code and coordinate with
>> Qemu utilities which may use same image. So, we want to support Qemu
>> file locking in the external code.
>>
>> So, here is a patch to document how Qemu locking works, and make this
>> thing "public".
>>
>> This is an RFC, because I'm unsure how should we actually document
>> different operations we have.
>>
>> For example greaph-mod is a strange thing, I think we should get rid
>> of it at all.. And at least, no sense in locking corresponding byte in a
>> raw file.
>>
>> The other thing is write-unchanged.. What it means when we consider a
>> raw file opened in several processes? Probably we don't need it too..
>>
>> docs/system/qemu-block-drivers.rst.inc | 55 ++++++++++++++++++++++++++
>> 1 file changed, 55 insertions(+)
>>
>> diff --git a/docs/system/qemu-block-drivers.rst.inc b/docs/system/qemu-block-drivers.rst.inc
>> index b052a6d14e..3cd708b3dc 100644
>> --- a/docs/system/qemu-block-drivers.rst.inc
>> +++ b/docs/system/qemu-block-drivers.rst.inc
>> @@ -952,3 +952,58 @@ on host and see if there are locks held by the QEMU process on the image file.
>> More than one byte could be locked by the QEMU instance, each byte of which
>> reflects a particular permission that is acquired or protected by the running
>> block driver.
>> +
>> +Image locking protocol
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +QEMU holds rd locks and never rw locks. Instead, GETLK fcntl is used with F_WRLCK
>> +to handle permissions as described below.
>> +QEMU process may rd-lock the following bytes of the image with corresponding
>> +meaning:
>> +
>> +Permission bytes. If permission byte is rd-locked, it means that some process
>> +uses corresponding permission on that file.
>> +
>> +Byte Operation
>> +100 read
>> + Lock holder can read
>> +101 write
>> + Lock holder can write
>> +102 write-unchanged
>> + Lock holder can write same data
>> +103 resize
>> + Lock holder can resize the file
>> +104 graph-mod
>> + Undefined. QEMU sometimes locks this byte, but external programs
>> + should not. QEMU will stop locking this byte in future
>> +
>> +Unshare bytes. If permission byte is rd-locked, it means that some process
>> +does not allow the others use corresponding options on that file.
>> +
>> +Byte Operation
>> +200 read
>> + Lock holder don't allow read operation to other processes.
>> +201 write
>> + Lock holder don't allow write operation to other processes.
>> +202 write-unchanged
>> + Lock holder don't allow write-unchanged operation to other processes.
>> +203 resize
>> + Lock holder don't allow resizing the file by other processes.
>> +204 graph-mod
>> + Undefined. QEMU sometimes locks this byte, but external programs
>> + should not. QEMU will stop locking this byte in future
>> +
>> +Handling the permissions works as follows: assume we want to open the file to do
>> +some operations and in the same time want to disallow some operation to other
>> +processes. So, we want to lock some of the bytes described above. We operate as
>> +follows:
>> +
>> +1. rd-lock all needed bytes, both "permission" bytes and "unshare" bytes.
>> +
>> +2. For each "unshare" byte we rd-locked, do GETLK that "tries" to wr-lock
>> +corresponding "permission" byte. So, we check is there any other process that
>> +uses the permission we want to unshare. If it exists we fail.
>> +
>> +3. For each "permission" byte we rd-locked, do GETLK that "tries" to wr-lock
>> +corresponding "unshare" byte. So, we check is there any other process that
>> +unshares the permission we want to have. If it exists we fail.
>>
>
>
--
Best regards,
Vladimir
next prev parent reply other threads:[~2021-06-22 11:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 18:27 [PATCH RFC] docs: document file-posix locking protocol Vladimir Sementsov-Ogievskiy
2021-05-24 14:40 ` Vladimir Sementsov-Ogievskiy
2021-06-22 11:14 ` Vladimir Sementsov-Ogievskiy [this message]
2021-06-22 12:00 ` Daniel P. Berrangé
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=bc400a16-3df4-30fd-9c6d-3cd5bbd00e4a@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=ktkhai@virtuozzo.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).