From: Niklas Cassel <cassel@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>
Subject: Re: [PATCH] block: Allow REQ_FUA|REQ_READ
Date: Tue, 11 Mar 2025 15:53:51 +0100 [thread overview]
Message-ID: <Z9BOf7WljNX-Rnl7@ryzen> (raw)
In-Reply-To: <20250311133517.3095878-1-kent.overstreet@linux.dev>
Hello Kent,
On Tue, Mar 11, 2025 at 09:35:16AM -0400, Kent Overstreet wrote:
> REQ_FUA|REQ_READ means "do a read that bypasses the controller cache",
> the same as writes.
>
> This is useful for when the filesystem gets a checksum error, it's
> possible that a bit was flipped in the controller cache, and when we
> retry we want to retry the entire IO, not just from cache.
Looking at ATA Command Set - 6 (ACS-6),
7.23 READ FPDMA QUEUED - 60h
"""
If the Forced Unit Access (FUA) bit is set to one, the device shall retrieve
the data from the non-volatile media regardless of whether the device holds
the requested information in the volatile cache.
If the device holds a modified copy of the requested data as a result of
having volatile cached writes, the modified data shall be written to the
non-volatile media before being retrieved from the non-volatile media as
part of this operation.
"""
So IIUC, at least for ATA, if something is corrupted in the volatile
write cache, setting the FUA bit will ensure that the corruption will
get propagated to the non-volatile media.
Kind regards,
Niklas
next prev parent reply other threads:[~2025-03-11 14:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 13:35 [PATCH] block: Allow REQ_FUA|REQ_READ Kent Overstreet
2025-03-11 14:53 ` Niklas Cassel [this message]
2025-03-11 15:09 ` Kent Overstreet
2025-03-11 15:13 ` Keith Busch
2025-03-11 15:02 ` Martin K. Petersen
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=Z9BOf7WljNX-Rnl7@ryzen \
--to=cassel@kernel.org \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=kent.overstreet@linux.dev \
--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