On Wed, Jul 16, 2025 at 8:50 PM Sean Mooney <smooney@redhat.com> wrote:
On 16/07/2025 14:32, Rajat Dhasmana wrote:
> to trim/sparcify the volume if the backend supports that?
This is really not helpful. Copying volume as sparse is not just to save space but also to improve performance and calling a new API is as easy/hard as executing the equivalent command on the backend side so it doesn't seem to be worth the effort.
so just to touch on this. from my perspective as a cloud user i may want to trigger the sparsification manually for a long time trim/discard was not supported on all backend so if i as an end user have a long live volume and esspically if if i have done a lot of deletions over time for data in that volume i can see a use case for it.
what i find more surprising is the concept that cinder would not consider the volume unsupported if you went out of band and did any operation on the storage backend directly.
like on the nova side if you as an operator ssh to a host and perform operations on the vm file or go to ceph and executed the operation directly on the ceph cluster for a nova provisioned ceph volume you would void your warranty.
i.e. if you go out of band and take snapshot of ceph volumes or something like that directly in ceph then any storage issues the vm has are yours to fix.
so im surprised you would discount the idea of a driver independent cinder api to allow triggering the apporate command on the backend and instead
encourage operator to do it them selves.
I'm not really encouraging anyone to do anything :) An API for sparsifying volumes will require a generic interface and a driver specific implementation across various vendors, given if they are motivated enough to implement their vendor specific logic for it. Such a solution doesn't exist so either we fix the "copy" operations to preserve sparseness or the operator can fix things on their own knowing the consequences of it.
also if this api existed and nova did the data transfer for the in use volume we could call it if the connection info says the backend support spareness or requested it.
We already do that with the "discard" parameter that sets the "driver_discard"[1] config for libvirt based on the value.
granted cinder could also just call it in that case after we tell cinder the retype is complete and the data is transferred.
that would not need any changes on the nova side which im ok with but if cinder want to make a guaretee of sparceness preservation on retype it
will have to handel the in-use case as well. otherwise it will remain best effort.
My final thoughts on this would be, we already provide a mechanism to report unmap/discard support for the Cinder backend and if the hypervisor|guest|bus support it, they can issue "fstrim". Although "fstrim" works at the filesystem level and sparsification on the backend will be at block level, an operator should be well versed with the pros and cons of each and how it will affect their overall deployment otherwise won't pursue it. I'm just stating what exists and what doesn't, also trying to fix what I can so I really don't vouch for any choice the operator makes (even the "rbd sparsify" workaround wasn't my recommendation). Hope that clarifies my take here.
To minimize the behavior change of existing functions, I think it would be effective to sparsify after retyping if the backend supports it.
[1] https://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/volum... Thanks Rajat Dhasmana