If there is any potential danger and no functional gain from sparsify then it doesn't seem like a good idea to run it, and definitely not on a running VM.
This cluster was created on 19.2.x. fast-diff and object-map should be on by default. "rbd du" takes a second or two to run. I've been looking at it for a week or so; the USED and OBJECTS change immediately after a sparsify but space used per PVE/"rbd df" doesn't functionally change other than the normal slight variance day to day, or a bit more one day or so each week which I assumed was TRIM. In other words, AFAICT, TRIM operates fine but doesn't change the "rbd du" USED output. Which by extension just increases over time, presumably up to the VM disk size. It will just look weird, eventually having more USED than cluster capacity, if anyone in the distant future runs that command (since PVE shows the actual used space). Currently bluestore_min_alloc_size = 4096 on all OSDs. bluestore_use_optimal_io_size_for_min_alloc_size defaults off, and says "It is a no-op for conventional media" but I can look into it. https://docs.ceph.com/en/latest/rados/configuration/bluestore-config-ref/#confval-bluestore_use_optimal_io_size_for_min_alloc_size > cool kids skate XFS "I used to be with 'it', but then they changed what 'it' was. Now what I'm with isn't 'it' anymore and what's 'it' seems weird and scary." 👴 -----Original Message----- From: Anthony D'Atri via ceph-users <[email protected]> Sent: Wednesday, March 11, 2026 9:58 AM To: Steve Yates <[email protected]> Cc: [email protected] Subject: [ceph-users] Re: Can rbd sparsify be run on a running VM's disk? > >> I'm about at the point of ignoring the "rbd du" USED number. It doesn't >> seem terribly meaningful. > If all of your clients are the equivalent of Luminous or later, do you have the fast-diff and object-map feature flags enabled by default and for existing volumes? They dramatically increase the speed of `rbd du`. Also, ISTR that there may be an asynchronous GC process where the freed capacity takes some time to show up. Maybe run the du again and see if it’s changed? > Sparsify really tries to find 0-filled objects that can be removed. It's best > to stick with > fstrim (or equivalent) in the guest. Agreed. Sparsify is best reserved for volumes that are currently unattached. > An OSD has a 4K (SSD) / 64K (HDD) threshold (bluestore_min_alloc_size) This used to default to 64 KiB; in the O/P era these values were split and varied a bit before both settling on 4 KiB. In recent releases they are both 4 KiB to reduce space amp, e.g. for tiny RGW objects. Note that despite some references on the net, you cannot effectively retrofit this value for an existing OSD. The process will report a runtime change, but it’s actually baked into the OSD and cannot be changed in practice without redeploying. From … Quincy I think it was, the baked-in value is reported by `ceph osd metadata`. Some outdated references suggest setting the value based on workload, I suggest not doing that unless you are using coarse-IU SSDs e.g. P4326, P5316, P5336, 6550, et al. I suggest setting bluestore_use_optimal_io_size_for_min_alloc_size to true before creating OSDs. I have never seen a case where it does the wrong thing. > EXT4 uses > All the cool kids skate XFS, warts and all ;) _______________________________________________ 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=dXNlcj1zdGV2ZUB0ZWFtaXRzLmNvbTt0cz0xNzczMjQxMTA3O3V1aWQ9NjlCMTgzMTI4Qjk4NkUzRUU2NDQ1NUIwQ0U3NEY1MkM7dG9rZW49Njg3MGVjNTYwYzEyYmUzODFjNWU3NjQwODU1NjE1ZjNlNTdlNzg5Mzs%3D). _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
