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.
>
Thanks
Rajat Dhasmana