[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v5 2/3] file-posix: Drop s->lock_fd
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-block] [PATCH v5 2/3] file-posix: Drop s->lock_fd |
Date: |
Wed, 14 Nov 2018 14:54:51 +0100 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Thu 11 Oct 2018 09:21:34 AM CEST, Fam Zheng wrote:
> The lock_fd field is not strictly necessary because transferring locked
> bytes from old fd to the new one shouldn't fail anyway. This spares the
> user one fd per image.
>
> Signed-off-by: Fam Zheng <address@hidden>
> Reviewed-by: Max Reitz <address@hidden>
One of my tests (not published yet) starts to fail after this
patch. Here's how you can reproduce the error:
$ qemu-img create -f qcow2 hd.qcow2 4G
$ qemu-system-x86_64 -qmp stdio
{ "execute": "qmp_capabilities" }
{ "execute": "blockdev-add", "arguments": {"driver": "qcow2", "node-name":
"hd0", "file": {"driver": "file", "filename": "hd.qcow2", "locking": "on" }}}
{ "execute": "human-monitor-command", "arguments": {"command-line": "qemu-io
hd0 \"reopen -o file.locking=on\""}}
{ "execute": "human-monitor-command", "arguments": {"command-line": "qemu-io
hd0 \"reopen -o file.locking=off\""}}
{ "execute": "blockdev-del", "arguments": {"node-name": "hd0"}}
{ "execute": "blockdev-add", "arguments": {"driver": "qcow2", "node-name":
"hd0", "file": {"driver": "file", "filename": "hd.qcow2"}}}
{"error": {"class": "GenericError", "desc": "Failed to get \"consistent read\"
lock"}}
Berto
- Re: [Qemu-block] [PATCH v5 2/3] file-posix: Drop s->lock_fd,
Alberto Garcia <=