Re: [Qemu-devel] [RFC] Block device size rounding

[Markus Armbruster]

John Snow <address@hidden> writes:

> On 10/12/2015 02:09 PM, Peter Crosthwaite wrote:
>> On Mon, Oct 12, 2015 at 9:26 AM, Eric Blake <address@hidden> wrote:
>>> On 10/12/2015 09:56 AM, John Snow wrote:
>>>
>>>>> What is the correct action here though? If the file is writeable should
>>>>> we just allow the device to extend its size? Is that possible already?
>>>>> Just zero-pad read-only?
>>>>>
>>>>
>>>> Read-only seems like an easy case of append zeroes.
>>>
>>> Yes, allowing read-only with append-zero behavior seems sane.

This is tolerable.  Do we want to warn?

A reopen can bring in the read/write case.

>>>> Read-write ... well, we can't write-protect just half of a 512k block.
>>>
>>>> Probably just forcibly increasing the size on RW or refusing to use the
>>>> file altogether are probably the sane deterministic things we want.
>>>
>>> I'd lean towards outright rejection if the file size isn't up to snuff
>>> for use as read-write.  Forcibly increasing the size (done
>>> unconditionally) still feels like magic, and may not be possible if the
>>> size is due to something backed by a block device rather than a file.

Concur.

>> Inability to extend is easily detectable and can become a failure mode
>> in it's own right. If we cant extend the file perhaps we can just
>> LOG_UNIMP the data writes? Having to include in your user instructions
>> "dd your already-on-SATA file system to this container just so it can
>> work for SD" is a pain.

Whenever QEMU proper can extend to the right size, qemu-img should be
able to do so as well, shouldn't it?  QEMU's error message could even
explain how.

> Fits within my "Always extend the size" answer. Failing to do so is a
> good cause to fail.
>
> I'm not sure if this is the sort of thing that might require an extra
> flag or option for compatibility reasons or not, though. If there is no
> precedent for QEMU resizing a block device to make it compatible with a
> particular device model, it's probably reasonable that no management
> tool is expecting this to happen automatically either.
>
> Then again, it's still annoying that the current default is definitely
> broken.
>
> I think this is going to boil down into an interface-and-expectations
> argument. I am otherwise in favor of just forcing the resize whenever
> possible and failing when it isn't.

I agree it's about expectations.

When I give QEMU read/write access to an image, I expect it to modify
the image, but I don't expect it to resize it on its own.  Perhaps my
expectation is wrong.  Do we have precedence?