From: James Bottomley <jejb@linux.ibm.com>
To: Bart Van Assche <bvanassche@acm.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Asutosh Das <asutoshd@codeaurora.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
Avri Altman <avri.altman@wdc.com>,
linux-scsi@vger.kernel.org, Bean Huo <beanhuo@micron.com>,
Stanley Chu <stanley.chu@mediatek.com>,
Jinyoung Choi <j-young.choi@samsung.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH 2/2] scsi: ufs: Use SYNCHRONIZE CACHE instead of FUA
Date: Thu, 02 Feb 2023 13:46:14 -0500 [thread overview]
Message-ID: <9d784606dfd75feefe653694d920b15e9dfcaff0.camel@linux.ibm.com> (raw)
In-Reply-To: <941ac8ba-8814-f3d5-ddc7-712058ea91ef@acm.org>
On Thu, 2023-02-02 at 10:09 -0800, Bart Van Assche wrote:
> On 2/1/23 23:52, Adrian Hunter wrote:
> > On 1/02/23 20:06, Bart Van Assche wrote:
> > > UFS devices perform better when using SYNCHRONIZE CACHE command
> > > instead of the FUA flag. Hence this patch.
> >
> > It would be nice to get some clarification on what is
> > going on for this case.
> >
> > This includes with Data Reliability enabled?
> >
> > In theory, WRITE+FUA should be at least as fast as
> > WRITE+SYNCHRONIZE CACHE, right?
> >
> > Do we have any explanation for why that would not
> > be true?
> >
> > In particular, is SYNCHRONIZE CACHE faster because
> > it is not, in fact, providing Reliable Writes?
> Hi Adrian,
>
> Setting the FUA bit in a WRITE command is functionally equivalent to
> submitting a WRITE command without FUA and submitting a SYNCHRONIZE
> CACHE command afterwards. For both sequences the storage device has
> to guarantee that the written data will survive a sudden power loss
> event.
Well, that may not be true in all situations. Semantically FUA is a
barrier: it can be implemented such that it destages only the current
write plus the cache writes that occurred before the write with the
FUA. It could also be implemented as you suggest above, which simply
destages the entire cache, but it doesn't have to be. One of the
reasons for FUA to exist is the potential difference between the two.
James
next prev parent reply other threads:[~2023-02-02 18:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 18:06 [PATCH 0/2] Use SYNCHRONIZE CACHE instead of FUA for UFS devices Bart Van Assche
2023-02-01 18:06 ` [PATCH 1/2] scsi: core: Introduce the BLIST_BROKEN_FUA flag Bart Van Assche
2023-02-01 18:06 ` [PATCH 2/2] scsi: ufs: Use SYNCHRONIZE CACHE instead of FUA Bart Van Assche
2023-02-02 1:54 ` Daejun Park
2023-02-02 4:32 ` kernel test robot
2023-02-02 7:52 ` Adrian Hunter
2023-02-02 18:09 ` Bart Van Assche
2023-02-02 18:46 ` James Bottomley [this message]
2023-02-02 19:00 ` Bart Van Assche
2023-02-02 22:13 ` James Bottomley
2023-02-02 9:01 ` kernel test robot
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=9d784606dfd75feefe653694d920b15e9dfcaff0.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=adrian.hunter@intel.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=j-young.choi@samsung.com \
--cc=jaegeuk@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=stanley.chu@mediatek.com \
/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