[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 2/5] block: Generic truncation fallback
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [RFC 2/5] block: Generic truncation fallback |
Date: |
Fri, 12 Jul 2019 12:58:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
On 12.07.19 11:49, Kevin Wolf wrote:
> Am 11.07.2019 um 21:58 hat Max Reitz geschrieben:
>> If a protocol driver does not support truncation, we call fall back to
>> effectively not doing anything if the new size is less than the actual
>> file size. This is what we have been doing for some host device drivers
>> already.
>
> Specifically, we're doing it for drivers that access a fixed-size image,
> i.e. block devices rather than regular files. We don't want to do this
> for drivers where the file size could be changed, but just didn't
> implement it.
>
> So I would suggest calling the function more specifically something like
> bdrv_co_truncate_blockdev(), and not using it as an automatic fallback
> in bdrv_co_truncate(), but just make it the BlockDriver.bdrv_co_truncate
> implementation for those drivers where it makes sense.
I was thinking about this, but the problem is that .bdrv_co_truncate()
does not get a BdrvChild, so an implementation for it cannot generically
zero the first sector (without bypassing the permission system, which
would be wrong).
So the function pointer would actually need to be set to something like
(int (*)(BlockDriverState *, int64_t, PreallocMode, Error **))42ul, or a
dummy function that just aborts, and then bdrv_co_truncate() would
recognize this magic constant. But that seemed so weird to me that I
decided just not to do it, mostly because I was wondering what would be
so bad about treating images whose size we cannot change because we
haven’t implemented it exactly like fixed-size images.
(Also, “fixed-size” is up to interpretation. You can change an LVM
volume’s size. qemu doesn’t do it, obviously. But that is the reason
for the warning qemu-img resize emits when it sees that the file size
did not change.)
> And of course, we only need these fake implementations because qemu-img
> (or .bdrv_co_create_opts) always wants to create the protocol level. If
> we could avoid this, then we wouldn't need any of this.
It’s trivial to avoid this. I mean, patch 4 does exactly that.
So it isn’t about avoiding creating the protocol level, it’s about
avoiding the truncation there. But why would you do that?
Max
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close(), (continued)
- Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close(), Kevin Wolf, 2019/07/12
- Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close(), Max Reitz, 2019/07/12
- Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close(), Kevin Wolf, 2019/07/12
- Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close(), Max Reitz, 2019/07/12
- Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close(), Kevin Wolf, 2019/07/12
[Qemu-devel] [RFC 3/5] block: Fall back to fallback truncate function, Max Reitz, 2019/07/11
[Qemu-devel] [RFC 2/5] block: Generic truncation fallback, Max Reitz, 2019/07/11
[Qemu-devel] [RFC 5/5] iotests: Add test for fallback truncate/create, Max Reitz, 2019/07/11
[Qemu-devel] [RFC 4/5] block: Generic file creation fallback, Max Reitz, 2019/07/11