cloud-hypervisor / cloud-hypervisor

A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.
https://www.cloudhypervisor.org
3.73k stars 421 forks source link

Discard/TRIM support in virtio-blk #5406

Open gorbak25 opened 1 year ago

gorbak25 commented 1 year ago

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?

rbradford commented 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.

gorbak25 commented 1 year ago

@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 commented 1 year ago

@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.