Re: [PATCH 5/5] vvfat: add support for "size" options

[Markus Armbruster <armbru@redhat.com>]

Clément Chigot <chigot@adacore.com> writes:

> On Fri, Oct 31, 2025 at 12:57 PM Kevin Wolf <kwolf@redhat.com> wrote:

[...]

>> Imagine the simple case of a qcow2 image file used for the VM. You get
>> things stacked like this:
>>
>>         virtio-blk
>>             |
>>             v
>>           qcow2
>>             |
>>             v
>>           file
>>
>> You need to open them from bottom to top. Opening a qcow2 image must be
>> able to read from the file, so first the file layer must be opened. And
>> obvious a virtio-blk device can only use the image after the qcow2
>> layered has been opened.
>>
>> In your case, this is raw over vvfat. vvfat gets opened first, and then
>> raw gets instantiated on top of it. (If you use format=vvfat, then the
>> raw layer is left away.)

Desirable, because it's simpler.

>> Top level options you give to -drive go to the topmost block driver. You
>> should be able to still set it on the vvfat level with -drive
>> format=raw,file.size=... Deciding which option goes to which node is
>> part of the (rather complicated) bdrv_open() logic in block.c.
>>
>> What raw does when a size option is given is that it just truncates the
>> lower level to the given size. So as vvfat doesn't know the size, it
>> still creates a 504 MB image, but raw shows only the first part of it to
>> the guest. This results not only in an invalid partition table, but also
>> means that as soon as vvfat decides to put a cluster after your limited
>> size, you'll see filesystem corruption in the guest.
>>
>> So your approach to deal with this in vvfat and create a smaller
>> filesystem to start with does look right to me.
>
> Ok thanks for the explanation. It's a bit counter-intuitive that
> "size" does not propagate to lower levels, especially if it generates
> wrong ones behind the scene.

Format "raw" was designed to do nothing, so we have a "do nothing"
format for the rigid "format over protocol" system.

We've long acquired the means to use a protocol without a format.  This
made "raw" redundant.  I advocate omitting it, because it only
complicates matters.

Except when you want the one feature "raw" provides beyond "do nothing":
carve a slice with options offset and size (commit 2fdc70452a5 "raw_bsd:
add offset and size options", 2016).

>                              But IIUC, this would be a much more
> complex patch (i.e. changing bdrv_open logic).

"size" is for slicing.  Can't see how it could simultaneously be
forwarded to the next block driver.

> Hence, I'm fine keeping this series narrowed to "format=vvfat".
>
>
>> Kevin
>>