From: Damien Le Moal <dlemoal@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: Zoned storage and BLK_STS_RESOURCE
Date: Tue, 17 Dec 2024 06:56:16 -0800 [thread overview]
Message-ID: <5534fce5-4fe3-4979-bb04-5cbddf613d0d@kernel.org> (raw)
In-Reply-To: <955aacae-7dde-41a2-8eb9-3bbeae8c3d18@acm.org>
On 2024/12/16 13:22, Bart Van Assche wrote:
> On 12/16/24 12:54 PM, Damien Le Moal wrote:
>> Yes. But I am still confused. Where is the problem ?
>
> Here:
> https://lore.kernel.org/linux-block/95ab028e-6cf7-474e-aa33-37ab3bccd078@kernel.org/.
> In that message another approach is
> suggested than what I described in my previous message.
OK. So you are talking about an issue that potentially can happen *if* you
modify zone write plugging to issue more than one write at a time per zone. This
issue of reordering cannot happen today as there is always at most one write per
zone in-flight.
> UFSHCI 3.0 controllers preserve the command order except if these are in
> a power-saving mode called auto-hibernation (AH8). When leaving that
> mode, commands are submitted in tag order (0..31). The approach
> described above provides an elegant solution for the unaligned write
> errors that can be caused by command reordering when leaving AH8 mode.
> I'm not aware of any other elegant approach to deal with the reordering
> that can be caused by leaving the UFSHCI AH8 mode.
As I said, I do not know enough about UFS to comment on potential solutions as I
do not fully grasp the problem.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2024-12-17 14:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 19:24 Zoned storage and BLK_STS_RESOURCE Bart Van Assche
2024-12-16 20:23 ` Damien Le Moal
2024-12-16 20:42 ` Bart Van Assche
2024-12-16 20:54 ` Damien Le Moal
2024-12-16 21:22 ` Bart Van Assche
2024-12-16 22:49 ` Damien Le Moal
2024-12-17 14:56 ` Damien Le Moal [this message]
2024-12-19 5:55 ` Christoph Hellwig
2024-12-19 17:07 ` Bart Van Assche
2024-12-17 4:15 ` Christoph Hellwig
2024-12-17 15:04 ` Damien Le Moal
2024-12-17 18:38 ` Bart Van Assche
2024-12-17 18:46 ` Jens Axboe
2024-12-17 18:51 ` Damien Le Moal
2024-12-17 19:07 ` Jens Axboe
2024-12-17 19:20 ` Damien Le Moal
2024-12-17 19:25 ` Bart Van Assche
2024-12-17 19:28 ` Damien Le Moal
2024-12-17 19:33 ` Jens Axboe
2024-12-17 19:37 ` Damien Le Moal
2024-12-17 19:41 ` Jens Axboe
2024-12-17 19:48 ` Damien Le Moal
2024-12-17 19:54 ` Jens Axboe
2024-12-17 19:58 ` Jens Axboe
2024-12-17 20:59 ` Damien Le Moal
2024-12-17 21:25 ` Jens Axboe
2024-12-18 6:58 ` Christoph Hellwig
2024-12-19 18:04 ` Bart Van Assche
2024-12-21 8:10 ` Christoph Hellwig
2025-01-06 18:54 ` Bart Van Assche
2024-12-19 6:00 ` Christoph Hellwig
2024-12-19 14:50 ` Jens Axboe
2024-12-19 17:12 ` Bart Van Assche
2024-12-19 23:10 ` Damien Le Moal
2025-01-06 20:14 ` Bart Van Assche
2024-12-21 8:13 ` Christoph Hellwig
2024-12-17 19:32 ` Jens Axboe
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=5534fce5-4fe3-4979-bb04-5cbddf613d0d@kernel.org \
--to=dlemoal@kernel.org \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--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;
as well as URLs for NNTP newsgroup(s).