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 <f...@redhat.com>
> Reviewed-by: Max Reitz <mre...@redhat.com>
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
