On 10/14/2011 04:32 PM, Kevin Wolf wrote:
> I can certainly drop aio_discard from the backends, but I'm not sure how
> heavy can fallocate be (with FALLOC_FL_PUNCH_HOLE). Probably not much,
> but I think there's no guarantee of O(1) behavior especially with
> filesystems like ecryptfs. So y
Am 14.10.2011 16:24, schrieb Paolo Bonzini:
> On 10/14/2011 04:23 PM, Kevin Wolf wrote:
>>> This similarly adds support for coroutine and asynchronous discard.
>>>
>>> Signed-off-by: Paolo Bonzini
>>
>> Do we really need bdrv_discard and bdrv_aio_discard in the backends? I
>> think it makes sense
On 10/14/2011 04:23 PM, Kevin Wolf wrote:
> This similarly adds support for coroutine and asynchronous discard.
>
> Signed-off-by: Paolo Bonzini
Do we really need bdrv_discard and bdrv_aio_discard in the backends? I
think it makes sense to have a bdrv_aio_discard() in block.h as AIO
generally
Am 14.10.2011 10:41, schrieb Paolo Bonzini:
> This similarly adds support for coroutine and asynchronous discard.
>
> Signed-off-by: Paolo Bonzini
Do we really need bdrv_discard and bdrv_aio_discard in the backends? I
think it makes sense to have a bdrv_aio_discard() in block.h as AIO
generally
This similarly adds support for coroutine and asynchronous discard.
Signed-off-by: Paolo Bonzini
---
I was not sure if qcow2 could be changed to co_discard, though
I suspected yes.
block.c | 72 +-
block.h |
