Hi, Some protocol drivers do not really support file truncation but still implement .bdrv_co_truncate(): They just don’t do anything when asked to shrink a file. This is reflected by qemu-img, which warns if you resize a file and it has the exact same length afterwards as it had before.
We can just do that generically. There is no reason for some protocol drivers to act ashamed and pretend nobody notices. The only thing we have to take care of is to zero everything in the first sector past the desired EOF, so that format probing won’t go wrong. (RFC: Is it really OK to just do this for all block drivers?) Similarly, we can add a fallback file creation path: If a block driver does not support creating a file but it already exists, we can just use it. All we have to do is truncate it to the desired size. This is an RFC because it feels weird and I don’t want people to associate me with weird stuff too closely. Well, patch 1 isn’t really an RFC. It’s just a fix. I was inspired to this series by Maxim’s patch “block/nvme: add support for image creation” (from his “Few fixes for userspace NVME driver” series). Max Reitz (5): block/nbd: Fix hang in .bdrv_close() block: Generic truncation fallback block: Fall back to fallback truncate function block: Generic file creation fallback iotests: Add test for fallback truncate/create block.c | 77 ++++++++++++++++++++++++++++++++------ block/file-posix.c | 21 +---------- block/io.c | 69 ++++++++++++++++++++++++++++++++-- block/nbd.c | 12 +++++- block/sheepdog.c | 2 +- tests/qemu-iotests/259 | 71 +++++++++++++++++++++++++++++++++++ tests/qemu-iotests/259.out | 20 ++++++++++ tests/qemu-iotests/group | 1 + 8 files changed, 235 insertions(+), 38 deletions(-) create mode 100755 tests/qemu-iotests/259 create mode 100644 tests/qemu-iotests/259.out -- 2.21.0