On 2026/10/13 14:39, Kyrylo Biryuk wrote:
> dmz_reclaim_work() re-arms its DMZ_IDLE_PERIOD poll only when
> dmz_should_reclaim() returns false at the start of a pass (and, with the
> first patch of this series, when a pass fails with -ENOSPC). After a pass
> it calls dmz_schedule_reclaim(), which queues the work only if reclaim
> is needed right now. When a pass ends while the target is still busy and
> has enough free zones, nothing is queued at all. Once the target goes
> idle, nothing re-evaluates dmz_should_reclaim() until another zone
> allocation, a "reclaim" message or a resume schedules the work, so the
> random or cache zones that filled up under load stay full.
>
> Seen on md RAID5 members on 27 TB host-managed drives: after heavy
> writes the random zones stayed full for hours on idle targets; the
> workaround was a timer sending "dmsetup message <dev> 0 reclaim". With
> this patch the emptied and filled zones were reclaimed within minutes of
> the targets going idle, without the timer.
>
> When reclaim is not needed right now, make dmz_schedule_reclaim() queue
> the idle poll, so the work stays queued after every pass. It uses
> queue_delayed_work(), which leaves already pending work alone, so the
> other callers (zone allocation and the "reclaim" message) neither
> postpone a pending poll nor delay a pending immediate reclaim.
>
> Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
> Assisted-by: LLM
> Signed-off-by: Kyrylo Biryuk <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
--
Damien Le Moal
Western Digital Research
