On Mon, 10 Nov 2025, Kevin Wolf wrote:
Am 10.11.2025 um 14:42 hat Markus Armbruster geschrieben:
Clément Chigot <[email protected]> writes:
On Mon, Nov 10, 2025 at 2:09 PM Markus Armbruster <[email protected]> wrote:
Clément Chigot <[email protected]> writes:
On Mon, Nov 10, 2025 at 11:13 AM Markus Armbruster <[email protected]> wrote:
Clément Chigot <[email protected]> writes:
This allows more flexibility to vvfat backend. The values of "Number of
Heads" and "Sectors per track" are based on SD specifications Part 2.
Due to the FAT architecture, not all sizes are reachable. Therefore, it
could be round up to the closest available size.
FAT32 has not been adjusted and thus still default to 504 Mib.
For floppy, only 1440 Kib and 2880 Kib are supported.
Signed-off-by: Clément Chigot <[email protected]>
[...]
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 8a479ba090..0bcb360320 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3478,11 +3478,17 @@
# (default: true)
# (since 10.2)
#
+# @fat-size: size of the device in bytes. Due to FAT underlying
+# architecture, this size can be rounded up to the closest valid
+# size.
+# (since 10.2)
+#
Can you explain again why you moved from @size to @fat-size?
Just to be sure, you mean in the above comment, in the commit message or both ?
Just to me, because I'm not sure I like the change, but that may well be
due to a lack of understanding of your reasons.
Naming `fat-size` instead of `size` ensures the parameter is only
recognized by the vvfat backend. In particular, it will be refused by
the default raw format, avoiding confusion:
"-drive file=fat:<path>,size=256M" results in a 504M FAT disk
truncated to 256M, raw format being implicit.
"-drive file=fat:<path>,fat-size=256M" is refused. "fat-size" is
unsupported by raw format.
I figure throwing in format=raw to make raw format explicit doesn't
change anything. Correct?
"-drive file=fat:<path>,format=vvfat,fat-size=256M" results in a 256M FAT disk.
"-drive file=fat:<path>,format=vvfat,size=256M" is refused. "size" is
unsupported by vvfat format.
If it was called @size, what behavior would we get? Just two cases, I
think:
1. With raw format:
-drive file=fat:<path>,size=256M
You'd silently get a 504 MiB filesystem truncated to 256 MiB (i.e. a
corrupted file system). It's quite easy to forget format=vvfat, so
something that initially looks like it might be working is not a great
result for this user error.
Why doesn't file=fat: imply format=vvfat? For what is the fat: part in
file then? I currently recommend using:
-drive if=none,id=ufat,format=raw,file=fat:rw:/dir/to/export
-device usb-storage,drive=ufat
to my users which I got from somewhere but don't remember where and it
seems to work but maybe not the best way to specify this. After reading
this thread I'm confused about how to use this correctly. Is there some
documentation on this? There only seems to be some mentions in
docs/system/qemu-block-drivers.rst.inc but all of them using older
options:
|qemu_system| linux.img -hdb fat:/my_directory
|qemu_system| linux.img -fda fat:floppy:/my_directory
|qemu_system| linux.img -fda fat:floppy:rw:/my_directory
Regards,
BALATON Zoltan
2. Without raw format:
-drive file=fat:<path>,format=vvfat,size=256M
This does the thing that you actually want, a 256 MiB file system.
I suggested to rename the vvfat option in v1 to make accidents at least
a bit less likely. I'm not completely sure if "fat-size" is the best
name, though, as it sounds as if it referred to the FAT itself instead
of the FAT filesystem. Maybe "fs-size"?
Kevin
