public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Zurcher, Christopher J" <christopher.j.zurcher@intel.com>
To: devel@edk2.groups.io
Cc: Michael D Kinney <michael.d.kinney@intel.com>,
	Jian J Wang <jian.j.wang@intel.com>,
	Liming Gao <liming.gao@intel.com>,
	Zhiguang Liu <zhiguang.liu@intel.com>
Subject: [PATCH v2 0/1] UefiScsiLib: Set FUA bit for synchronous SCSI Write operations
Date: Thu, 26 Mar 2020 00:34:23 -0700	[thread overview]
Message-ID: <20200326073424.69960-1-christopher.j.zurcher@intel.com> (raw)

V2 changes:
Add bit defines for cache control parameters from SBC-2.

Some SCSI devices have very aggressive write caching implemented, causing
data to be lost if the system is shut down or rebooted soon after
receiving a successful write confirmation from the device. By setting the
FUA bit in the synchronous versions of the Write10/Write16 commands, the
write cache is skipped and data is forced directly to the disk.

The Asynchronous (WriteEx) commands will not have this bit set, allowing
performance-sensitive transactions to continue utilizing the write cache.

An alternative, more complicated solution would be to implement the
SYNCHRONIZE CACHE command and call it from ScsiDiskFlushBlocks, which
currently returns EFI_SUCCESS without flushing anything. Since the
SYNCHRONIZE CACHE command requires the caller to provide the specific
blocks to flush, and the BlockIO FlushBlocks function does not accept any
arguments, this would require keeping track of the write history inside the
ScsiDiskDxe driver.

I have not tested the asynchronous commands for this issue, so there is a
chance that resetting the system even after a call to FlushBlocksEx might
still result in lost data. Currently the ScsiDiskFlushBlocksEx command
waits for the BlockIo2 requests queue to empty, but does not ask the device
itself to flush anything. (EFI_SCSI_OP_SYNC_CACHE is defined in
IndustryStandard/Scsi.h but is not implemented anywhere.)

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>

Christopher J Zurcher (1):
  MdePkg/UefiScsiLib: Set FUA bit for synchronous SCSI Write operations

 MdePkg/Include/IndustryStandard/Scsi.h   |  8 +++++++-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 14 ++++++++------
 2 files changed, 15 insertions(+), 7 deletions(-)

-- 
2.16.2.windows.1


             reply	other threads:[~2020-03-26  7:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26  7:34 Zurcher, Christopher J [this message]
2020-03-26  7:34 ` [PATCH v2 1/1] MdePkg/UefiScsiLib: Set FUA bit for synchronous SCSI Write operations Zurcher, Christopher J
2020-03-30  1:52   ` Zhiguang Liu
2020-03-30 13:51     ` Liming Gao
2020-03-30 20:34       ` Zurcher, Christopher J
2020-04-14 15:53         ` Liming Gao

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-list 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=20200326073424.69960-1-christopher.j.zurcher@intel.com \
    --to=devel@edk2.groups.io \
    /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