Open gorbak25 opened 1 year ago
I think an implementation of the virtio-block write zeroes feature seems reasonable. The challenge would be integrating it with the block abstraction / io_uring support.
@rbradford I don't see a challenge with exposing those methods using io_uring. I would add methods for discard/write_zeroes to the AsyncIO trait which under the hood would be mapped to appropriate fallocate io_uring calls(FALLOC_FL_ZERO_RANGE for write_zeroes and FALLOC_FL_PUNCH_HOLE for discard). Is it correct to assume that those fallocate calls would be mapped to discard/write_zeros operations on the block device layer?
@rbradford I don't see a challenge with exposing those methods using io_uring. I would add methods for discard/write_zeroes to the AsyncIO trait which under the hood would be mapped to appropriate fallocate io_uring calls(FALLOC_FL_ZERO_RANGE for write_zeroes and FALLOC_FL_PUNCH_HOLE for discard). Is it correct to assume that those fallocate calls would be mapped to discard/write_zeros operations on the block device layer?
I think we would only want to expose the virtio feature if the underlying backing file supports it e.g. raw files - yes, qcow, etc, no. Not sure about raw files that are block devices themselves like LVM devices.
Right now cloud hypervisor does not support discard/write_zeroes operations. This is highly problematic for my usecase as I rely on sparse file backed storage and I need to run the guest with online discard enabled in order to not trash the host disk.
I am willing to spend some time on getting that feature implemented. If a PR implementing this feature was submitted would it be in the scope of cloud-hypervisor or was it a design decision to not include those features?