[Devel] [PATCH hci-8.1 0/2] dm-qcow2, dm-ploop: do not merge discards with gaps

[Konstantin Khorenko]

Applying with these fixes on my side:
- 1/2: the example replaced with one that can happen on dm-qcow2,
  with units, plus what the user sees
- 2/2: the example replaced with one that loses data on dm-ploop,
  plus what the user sees
- both: "range in the file" -> "range of the device", "always"
  dropped, why the limit is USHRT_MAX, paragraphs

On Mon, 09 Nov 2026 18:36:17 +0300, Andrey Zhadchenko wrote:
> Both dm-qcow2 and dm-ploop handle a discard request as one contiguous
> range taken from blk_rq_pos() and blk_rq_bytes(). For a request built
> from bios [0, 512) and [1024, 1536) they discard [0, 1024), which hits
> sectors that were never asked to be discarded and misses part of the
> range that was.

Read in sectors, a 1024-sector discard request cannot be built on
dm-qcow2 with the default 64K cluster: max_hw_discard_sectors is one
cluster, and the merge is refused past it. On dm-ploop the example is
half a cluster, and ploop ignores discards that do not cover a whole
cluster, so nothing is lost there. The patch messages now carry an
example per target.

dm-tracking and dm-push-backup need the same limit, I filed a bug for
that:
https://virtuozzo.atlassian.net/browse/VSTOR-154423

Both take a discard request as one blk_rq_pos()/blk_rq_bytes() range,
and they inherit max_discard_segments from the origin. Over a patched
ploop or qcow2 that is 1, but over an origin with multi-range discard
(nvme, virtio-blk) they track the wrong clusters. Please send a
separate patch that gives both targets .io_hints with
max_discard_segments = 1.

-- 
Konstantin Khorenko,
Virtuozzo Linux Kernel Team