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

[John Snow <jsnow@redhat.com>]

On 10/13/2015 11:30 AM, Peter Crosthwaite wrote:
> On Tue, Oct 13, 2015 at 2:14 AM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 12.10.2015 um 20:26 hat John Snow geschrieben:
>>>
>>>
>>> On 10/12/2015 02:09 PM, Peter Crosthwaite wrote:
>>>> On Mon, Oct 12, 2015 at 9:26 AM, Eric Blake <eblake@redhat.com> 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.
>>>>>
>>>>>>
>>>>>> 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.
>>
>> Agreed, let's just reject the image for r/w. Image resize should always
>> been an explicit action invoked by the user, not a side effect of using
>> the image with a specific device.
>>
>>>> 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.
>>>>
>>>> Regards,
>>>> Peter
>>>>
>>>
>>> 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.
>>
>> That's not so clear to me. Strictly speaking, this is really a user
>> error because the user passed an image that isn't suitable for the
>> device. All we're discussing is handling this user error friendlier.
>>
>> Maybe we should take a step back: What's the specific use case here,
>> i.e. where does the misaligned image come from and what is it used for?
> 
> An ext filesystem image built by the Yocto build system. It is passed
> straight to QEMU as a raw image. The user does not create disk images,
> they are done by the build system. Note that the build system is not
> QEMU specific, it is designed to target either QEMU or be used for
> some form of real-hardware deployment so padding there is
> inappropriate.
> 
>> I assume this is not an image created with qemu-img, because then the
> 
> I am not using qemu-img at all.
> 
>> obvious options would already result in an aligned size.
>>
> 
> Maybe. What is the alignment of qemu-img? Note this requires 512K
> alignment, which is kinda huge.
> 
>>> 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'm strongly objecting to any automagic resizing of images.
>>
> 
> Can we LOG_UNIMP writes to the missing sectors? The the user can RW to
> the in-band sectors which should contain the limit of a pre-existing
> filesystem.
> 

This sounds potentially dangerous. Do we know for sure any data written
here is unimportant?

If it's all zeroes, we can probably guess it's unimportant. As soon as
any non-zero data lands up in this extension range... how do we assert
that this is garbage?

I don't think we can...

> Regards,
> Peter
> 
>> Kevin