[Devel] [PATCH hci-8.1 v11 08/10] dm-qcow2: leak clusters allocated for a failed L1/L2 writeback
Konstantin Khorenko
khorenko at virtuozzo.com
Mon Nov 9 18:42:38 MSK 2026
I won't apply this version, please send v12 with the changes below.
On 11/9/26 15:01, Alexander Ivanov wrote:
> spin_unlock_irqrestore(&qcow2->md_pages_lock, flags);
>
> + list_for_each_entry(qio, &end_list, link)
> + qio->ext->cleanup_mask &= ~FREE_ALLOCATED_CLU;
> qcow2_dispatch_qios(qcow2, NULL, &wait_list);
Item 1 of the cover letter reply: queue the L1-allocation qio on
l1.md->wbd->dependent_list instead of l1.md->wait_list.
Why: that qio does not reach end_list. It waits on l1.md->wait_list,
and on a failed L1 writeback clear_writeback_status() sends it back to
work. The reverted L1 entry is 0 again, so it allocates another
L2-table cluster, and the L1 page is written again in the same worker
pass. Nothing slows this down: with a persistent L1 write error every
round leaks one more cluster and grows the file. Before this patch the
same loop freed the cluster and reused it.
On success a dependent qio goes back to work the same way as a waiter,
so moving it costs nothing there. Today only the qios added in
process_indexes_write() sit on dependent_list, and they all have ext.
A plain write that allocates an L2 table may have none, so check
qio->ext in the new loop.
> Keep the refcount of these clusters instead. If L1/L2 on disk points to
> such a cluster, the image stays consistent; otherwise the cluster is
> leaked, which check repairs by freeing it. So the image needs no check
> and resume needs no refusal.
Item 2 of the cover letter reply: say what is leaked, one cluster per
failed L1/L2 write of a request.
Why: your v10 answer bounded the leak by "refcounts reach the disk
before L1/L2". In this driver it is the other way round: R1/R2 pages
wait on slow_wb_batch_list for the timer (see the comment above
mark_cluster_used()), while L1/L2 pages are written in the same worker
pass. And an L1 update has no data write that could fail first.
--
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
More information about the Devel
mailing list