Clément Chigot <[email protected]> writes: > On Fri, Oct 31, 2025 at 12:57 PM Kevin Wolf <[email protected]> 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 >>
