Hi Alwin,

Thanks for the input.  Sounds like "stopped" is the safe way, which is what I'd 
assumed.  It would be good if that was clarified in the Ceph docs 
(https://docs.ceph.com/en/latest/man/8/rbd/#:~:text=sparsify).

I found in the Proxmox forum thread that if I create 1+10 GB in two zero files 
on a small VM, delete, and trim, "rbd du" USED remained at 37/43 GB for that 
VM, so that doesn't help.  Also same issue on Windows VMs, and we have at least 
one (a pfSense VM) using ZFS, so it's not just EXT4.

Re: the serverfault thread, rebooting a VM results in no change in "rbd du" 
USED.  We do regularly reboot VMs for updates, and migrate too when rebooting 
PVE nodes.

I'm about at the point of ignoring the "rbd du" USED number.  It doesn't seem 
terribly meaningful.


-----Original Message-----
From: Alwin Antreich via ceph-users <[email protected]> 
Sent: Wednesday, March 11, 2026 6:27 AM
To: Steve Yates <[email protected]>
Cc: [email protected]
Subject: [ceph-users] Re: Can rbd sparsify be run on a running VM's disk?

Hi Steve,

I'd advise against using sparsify, especially on any mapped RBD (running
VM). We had a support case once where this operation on a live VM caused an
OSD lockup, halting the operation for other clients. Sparsify really tries
to find 0-filled objects that can be removed. It's best to stick with
fstrim (or equivalent) in the guest.

rbd du estimates size cheaply by counting the number of objects and
multiplying that count by the set object size. Therefore it diverges from
the size you see of the guest's filesystem.
Some additional points may contribute to the difference:
 * An OSD has a 4K (SSD) / 64K (HDD) threshold (bluestore_min_alloc_size)
for discard operations, meaning any discard smaller than this threshold is
ignored.
 * Disk encryption often doesn't clear block for security.
 * EXT4 uses an in-memory bitmap that does not trim blocks if they haven't
been overwritten before.
   This safeguards against wear on consumer SSDs but has the disadvantage
that a storage move will thick-allocate the disk and an fstrim isn't
clearing it.
   The only option is to write a big file and delete it or reboot. See:
https://forum.proxmox.com/threads/help-with-trim-on-virtio-scsi-single.123819/#post-539360

I hope this helps.

Cheers,
Alwin

On Tue, 10 Mar 2026 at 14:59, Steve Yates via ceph-users <[email protected]>
wrote:

> Question: Can rbd sparsify safely be run on a running VM's disk, in Ceph
> 19/Squid?  Or must the VM be shut down first?  I tried looking online but
> am not finding a direct answer.
>
> More info: I'm looking into why "rbd du" shows usage inconsistent with
> "ceph df" or Proxmox's "usage" displays (Proxmox thread<
> https://forum.proxmox.com/threads/ceph-rbd-du-shows-usage-2-4x-higher-than-inside-vm.181348/>).
> Sparsify on a stopped VM reduces "rbd du" usage, and the number of objects,
> but doesn't change the amount of space used according to Ceph and PVE.  I
> am wondering if sparsify can be safely scripted.  Or if I should just
> ignore "rbd du" USED amounts.
>
> Thanks.
> _______________________________________________
> ceph-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>


-- 
Alwin Antreich
Head of Training and Proxmox Services

Want to meet: https://calendar.app.google/MuA2isCGnh8xBb657

croit GmbH, Freseniusstr. 31h, 81247 Munich
CEO: Martin Verges, Andy Muthmann - VAT-ID: DE310638492
Com. register: Amtsgericht Munich HRB 231263
Web <https://croit.io/> | LinkedIn <http://linkedin.com/company/croit> |
Youtube <https://www.youtube.com/channel/UCIJJSKVdcSLGLBtwSFx_epw> | Twitter
<https://twitter.com/croit_io>

TOP 100 Innovator Award
<https://croit.io/blog/croit-receives-top-100-seal> Winner
by compamedia
Technology Fast50 Award
<https://croit.io/blog/deloitte-technology-fast-50-award> Winner by Deloitte
_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

------------------------------------
This email has been scanned for spam & viruses. If you believe this email 
should have been stopped by our filters, click the following link to report it 
(https://portal.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zdGV2ZUB0ZWFtaXRzLmNvbTt0cz0xNzczMjI4NDAxO3V1aWQ9NjlCMTUxNzBBRERBMjUxOUJFODUxNTAxMzFDNzY2RkI7dG9rZW49YWI3M2RkN2E0NmQzNmEyMDQ2MjgzNjljZTZjZTYyZWYwNmVhM2I3NDs%3D).
_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to