public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
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

  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