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. 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. 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.
To minimize the behavior change of existing functions, I think it would be effective to sparsify after retyping if the backend supports it.