qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] block: Update flags in bdrv_set_read_only()


From: Kevin Wolf
Subject: Re: [Qemu-devel] block: Update flags in bdrv_set_read_only()
Date: Mon, 14 Jan 2019 12:01:04 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

Am 12.01.2019 um 18:08 hat Michael Tokarev geschrieben:
>     commit eeae6a596b0efc092f5101c67683053e245e6250
>     Author: Kevin Wolf <address@hidden>
>     Date:   Tue Oct 9 16:57:12 2018 +0200
> 
>         block: Update flags in bdrv_set_read_only()
> 
>         To fully change the read-only state of a node, we must not only change
>         bs->read_only, but also update bs->open_flags.
> 
> sort of broke vfat support:
> 
>  $ qemu-system-x86_64 -hda fat:foo/
>  WARNING: Image format was not specified for 'json:{"fat-type": 0, "dir": 
> "foo/", "driver": "vvfat", "floppy": false, "rw": false}' and probing guessed 
> raw.
>           Automatically detecting the format is dangerous for raw images, 
> write operations on block 0 will be restricted.
>           Specify the 'raw' format explicitly to remove the restrictions.
>  qemu-system-x86_64: Initialization of device ide-hd failed: Block node is 
> read-only
>  $ _
> 
> The warning is annoying but harmless, but the read-only error is fatal.
> 
> "Sort-of" is because there's a somewhat strange workaround:
> 
>   -hda fat:rw:foo/
> 
> but it is a bit more dangerous as well.
> 
> It looks like vfat should be handled differently somewhere, to
> eliminate both the warning and the error?

Hm... This is not nice, but obviously that patch is still correct.

Essentially what you're saying is either:

1. We want to be able to attach read-only backends to read-write guest
   devices sometimes. If you actually do a write request then, you'll
   get an I/O error,

   or

2. vvfat shouldn't expose a read-only backend, but a read-write one that
   always fails when you write.

I think 2. is easier to implement, but it's special casing vvfat. Does
this make sense or is it a problem that needs to be solved more
generically? If it's okay for a read-only FAT backend to be attached to
an IDE disk that really needs a read-write backend, why wouldn't it be
okay to attach e.g. a read-only HTTP backend? Or even a read-only image
file on the local filesystem?

On the other hand, usually users wouldn't want to silently get a guest
started up that produces I/O errors on the first write request when they
just configured things wrong or have the wrong file permissions.

We can't do both at the same time, though. So what is the behaviour that
we actually want regarding read-only backends and read-write guest
devices?

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]