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 _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
