From: Damien Le Moal <dlemoal@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Subject: Re: [PATCH v2 1/7] block: fix zone write plug removal
Date: Fri, 27 Feb 2026 07:44:29 +0900 [thread overview]
Message-ID: <0d4f4fc7-a038-4c08-9aed-fd563abaa119@kernel.org> (raw)
In-Reply-To: <aaBwiGGrS5StFlWX@infradead.org>
On 2/27/26 01:10, Christoph Hellwig wrote:
> On Thu, Feb 26, 2026 at 01:10:18PM +0900, Damien Le Moal wrote:
>> /*
>> - * Check that a BIO completion or a zone reset or finish
>> - * operation has not already removed the zone write plug from
>> - * the hash table and dropped its reference count. In such case,
>> - * we need to get a new plug so start over from the beginning.
>> + * We already have a zone write plug. If it is flagged as dead,
>> + * its initial reference count was already dropped. In
>> + * this case, increment the reference count and clear the dead
>> + * flag to restore the plug to a state similar to a newly
>> + * allocated zone write plug.
>
> This comment, both in the old and new version describes what happens
> here, but it really fails to explain why. The plug is scheduled
> for removal if we either filled up the zone or reset it, so any new
> bio coming in would result in an I/O error anyway. So why do we try
> to resurrect the plug instead of just failing the I/O?
Hmm, yes, I guess we could do that indeed.
This case can happen only if the user starts doing stupid things like issuing a
zone reset and writes from the beginning of the zone without waiting for the
reset first. So yes, I guess we can fail the BIO if it hits a dead zone, since
that necessarily mean that the user did not synchronize something that should be.
I will drop that bit and instead print a rate limited error message signaling
the bad usage.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2026-02-26 22:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 4:10 [PATCH v2 0/7] Improve zoned (SMR) HDD write throughput Damien Le Moal
2026-02-26 4:10 ` [PATCH v2 1/7] block: fix zone write plug removal Damien Le Moal
2026-02-26 16:10 ` Christoph Hellwig
2026-02-26 22:44 ` Damien Le Moal [this message]
2026-02-26 4:10 ` [PATCH v2 2/7] block: fix zone write plugs refcount handling in disk_zone_wplug_schedule_bio_work() Damien Le Moal
2026-02-26 16:11 ` Christoph Hellwig
2026-02-27 7:12 ` Johannes Thumshirn
2026-02-26 4:10 ` [PATCH v2 3/7] block: remove disk_zone_is_full() Damien Le Moal
2026-02-26 16:11 ` Christoph Hellwig
2026-02-26 4:10 ` [PATCH v2 4/7] block: rename struct gendisk zone_wplugs_lock field Damien Le Moal
2026-02-26 16:12 ` Christoph Hellwig
2026-02-26 4:10 ` [PATCH v2 5/7] block: allow submitting all zone writes from a single context Damien Le Moal
2026-02-26 16:16 ` Christoph Hellwig
2026-02-26 4:10 ` [PATCH v2 6/7] block: default to QD=1 writes for blk-mq rotational zoned devices Damien Le Moal
2026-02-26 16:16 ` Christoph Hellwig
2026-02-26 4:10 ` [PATCH v2 7/7] Documentation: ABI: stable: document the zoned_qd1_writes attribute Damien Le Moal
2026-02-26 16:17 ` Christoph Hellwig
2026-02-26 22:17 ` [PATCH v2 0/7] Improve zoned (SMR) HDD write throughput Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d4f4fc7-a038-4c08-9aed-fd563abaa119@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox