Hi Robert, here is a brief overview on these parameters: bdev_enable_discard - flag to enable/disable trimming. Once enabled and depending on bdev_async_discard_threads parameter discard requests could be issued either synchronously or asynchronously. Each requests originates when OSD releases specific disk extent, e.g. when overwriting or removing an object (or part of it). In async mode requests are put into a queue and are processed by one of relevant threads. bdev_async_discard_threads - amount of threads to process discard requests asynchronously, if set to 0 and bdev_enable_discart is set to true - all the discard request are issued synchronously bdev_async_discard - this is a deprecated parameter, please don't use it I have no idea how this supposed to work with qcow2 files as the primary targets are SSD drives but in recent Ceph releases (e.g. v19.2.3 and upcoming v18.2.8) one can learn the amount of issued discard requests from OSD perf counters: ceph tell osd.0 perf dump | grep discard -B 1 "blk-kernel-device-bluestore": { "discard_op": 0, "discard_threads": 0 -- "blk-kernel-device-db": { "discard_op": 0, "discard_threads": 0 -- "blk-kernel-device-slow": { "discard_op": 0, "discard_threads": 0 -- "blk-kernel-device-wal": { "discard_op": 0, "discard_threads": 0 Hope this is helpful. Best regards, Igor On 17/02/2026 12:15, Robert Sander via ceph-users wrote:
Hi,
what is the purpose and effect of these configuration options?
bdev_async_discard bdev_async_discard_threads bdev_enable_discard
They are not mentioned on docs.ceph.com.
They read as they would enable a regular trim job on OSDs where the hardware supports trimming/discarding. How often would this operation run?
On a virtual test cluster where the OSDs are backed with qcow2 files and are presented to the VM as SSDs with discard they seem to have no effect on the size of the qcow2 file.
With a normal filesystem an fstrim operation will reduce the size of the qcow2 file.
Regards