On 10/16/18 9:12 AM, Kevin Wolf wrote:
Am 12.10.2018 um 19:02 hat Eric Blake geschrieben:
On 10/12/18 6:55 AM, Kevin Wolf wrote:
Some block drivers have traditionally changed their node to read-only
mode without asking the user. This behaviour has been marked deprecated
since 2.11, expecting users to provide an explicit read-only=on option.
Now that we have auto-read-only=on, enable these drivers to make use of
the option.
This is the only use of bdrv_set_read_only(), so we can make it a bit
more specific and turn it into a bdrv_apply_auto_read_only() that is
more convenient for drivers to use.
Signed-off-by: Kevin Wolf <kw...@redhat.com>
---
Worth documenting the -EINVAL (copy-on-read prevents setting read-only)
failure as well? (The -EPERM failure of bdrv_can_set_read_only() is not
reachable, since this new function never clears readonly).
In fact, -EINVAL and the error string from bdrv_can_set_read_only() may
be confusing because the user didn't explicitly request a read-only
image. Maybe it would be better to just turn this case into -EACCES with
the same error message.
What do you think?
So, how would it trigger in practice? The user requests a copy-on-read
action with the BDS as destination (thus the BDS must be writable, and
can't be set to readonly); they omitted read-only (because they know
they want copy-on-read); they supplied auto-read-only=true (because they
are lazy and want to always use that flag if it is available); but the
particular BDS they selected is not writable (whether read-only file
system, read-only NBD server, etc). In short, we can't grant them
read-write to begin with, and can't gracefully fall back to read-only
because it would violate their request for copy-on-read, so as long as
we give them a sane error message about their request being impossible,
we're good. Yes, -EACCES sounds reasonable, if you want to code that in.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
