On Wed, 2019-04-03 at 12:15 +-0800, Ming Lei wrote:
+AD4 Still not sure if it is safe to do that in case of SDEV+AF8-BLOCK.
+AD4
+AD4 SDEV+AF8-BLOCK can be set via sysfs interface, then what if there are
+AD4 in-flight IOs which need EH to retry just after someone sets 'blocked'?
+AD4
+AD4 People may complain this patch causes data loss on above test case.
Hi Ming,
scsi+AF8-send+AF8-eh+AF8-cmnd() is only used to request sense data, to submit a TUR or
to submit a START UNIT. None of these commands modify the data stored on
the SCSI device so there is no risk of data loss.
The ability to modify the SCSI device state was introduced by commit
638127e579a4 (+ACIAWw-PATCH+AF0 Fix error handler offline behaviour+ACIAOw v2.6.12). That
same commit introduced the following device states:
+AHs SDEV+AF8-CREATED, +ACI-created+ACI +AH0,
+AHs SDEV+AF8-RUNNING, +ACI-running+ACI +AH0,
+AHs SDEV+AF8-CANCEL, +ACI-cancel+ACI +AH0,
+AHs SDEV+AF8-DEL, +ACI-deleted+ACI +AH0,
+AHs SDEV+AF8-QUIESCE, +ACI-quiesce+ACI +AH0,
+AHs SDEV+AF8-OFFLINE, +ACI-offline+ACI +AH0,
The SDEV+AF8-BLOCK state was introduced later to avoid that an FC cable pull
would immediately result in an I/O error (commit 1094e682310e+ADs +ACIAWw-PATCH+AF0
suspending I/Os to a device+ACIAOw v2.6.12). I'm not sure whether the ability to
set the SDEV+AF8-BLOCK state from user space was introduced on purpose or
accidentally.
I think there are three alternatives:
(1) Accept that some error handling steps are skipped if a user sets the
device state to +ACI-blocked+ACI.
(2) Prevent users to change the device state to +ACI-blocked+ACI.
(3) Split SDEV+AF8-BLOCK into SDEV+AF8-BLOCKED+AF8-BY+AF8-USER and SDEV+AF8-BLOCKED+AF8-BY+AF8-TRANSPORT
and only skip sending EH commands to the device in state
SDEV+AF8-BLOCKED+AF8-BY+AF8-TRANSPORT.
Thanks,
Bart.
