search

firecracker-microvm / firecracker

Secure and fast microVMs for serverless computing.
http://firecracker-microvm.io
Apache License 2.0
26.36k stars 1.83k forks source link

Unmap/discard/fstrim #2708

Open sheepa opened 3 years ago

sheepa commented 3 years ago

Is firecracker supporting unmap/discard/fstrim, ie automatic reduction of the image size on the host when a file is deleted on the guest? If it does how do I enable it?

acatangiu commented 3 years ago

Hi @sheepa,

Firecracker does not support automatic reduction of the image size on the host when a file is deleted on the guest.

Firecracker emulates raw block devices with fixed capacity. Furthermore, Firecracker does not monitor or introspect guest operations so it has no information around the contents of guest disks (such as current use %).

What you describe would come with non-negligible overhead and would require guest cooperation to find out which ranges of the backing file can be dropped; so it would add a lot of complexity. What is your usecase? Why is this important?

raduweiss commented 3 years ago

@sheepa we will be tracking this as a new feature request that we have not yet taken on to our roadmap. Folks that could use this, feel free to comment. We will also actively get feedback here from other users as settle our 2022 roadmap.

crappycrypto commented 3 years ago

It seems like a good feature for longer running VMs to be able to release disk space on the host using discard. It might not be the primary use case for firecracker, but I occasionally leave firecracker running for days and it would be nice to be able to release disk space without recreating the VM.

At a first glance the implementation shouldn't be that difficult for a simple file backed disk. A single discard command can be converted into a set of calls like fallocate(fd, FALLOC_FL_PUNCH_HOLE| FALLOC_FL_KEEP_SIZE , offset, len)

Supporting it completely however quickly uncovers more features that might be implemented as well. For example for disks which are backed by a block device on the host we need to use the BLKDISCARD ioctl. And implementing discard also raises the question of whether firecracker should support the write zeroes command as well.

sheepa commented 2 years ago

Circling back after almost a year, sorry for the late reply;

What is your usecase? Why is this important? - @raduweiss

For long running processes, if firecracker is to be used as an alternative to qemu it would need unmap, the same goes for memory.

I really love firecracker but without it I cannot use it. Is there a roadmap for this? I cannot seem to find it.

goireu commented 1 year ago

Hi folks, I have another use case here.

I have an application that may or may not be long lived depending on how the end user configures it (can be configured to shut down on idle, in such case the customer agrees to sometimes cope with a wake-up delay for a reduced bill). In this scenario, customers which want to go idle also want fast wake up, customers which prefer always-on don't need this.

As a platform maintainer, I really don't want to choose between Firecracker or QEMU depending on customer's configuration, it makes no sense engineering-wise.

In my specific scenario, I don't really care about RAM release because I don't over-provision RAM, but discard is important because the underlying storage is a mutualized CEPH.

ShadowCurse commented 1 month ago

Hi everyone, We are not currently work on this feature, but we are open for a PR with this change. Some notes on the potential implementation: