On Wed, 2019-04-03 at 12:15 +0800, Ming Lei wrote:
> Still not sure if it is safe to do that in case of SDEV_BLOCK.
>
> SDEV_BLOCK can be set via sysfs interface, then what if there are
> in-flight IOs which need EH to retry just after someone sets 'blocked'?
>
> People may complain this patch causes data loss on above test case.
Hi Ming,
scsi_send_eh_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 ("[PATCH] Fix error handler offline behaviour"; v2.6.12). That
same commit introduced the following device states:
{ SDEV_CREATED, "created" },
{ SDEV_RUNNING, "running" },
{ SDEV_CANCEL, "cancel" },
{ SDEV_DEL, "deleted" },
{ SDEV_QUIESCE, "quiesce" },
{ SDEV_OFFLINE, "offline" },
The SDEV_BLOCK state was introduced later to avoid that an FC cable pull
would immediately result in an I/O error (commit 1094e682310e; "[PATCH]
suspending I/Os to a device"; v2.6.12). I'm not sure whether the ability to
set the SDEV_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 "blocked".
(2) Prevent users to change the device state to "blocked".
(3) Split SDEV_BLOCK into SDEV_BLOCKED_BY_USER and SDEV_BLOCKED_BY_TRANSPORT
and only skip sending EH commands to the device in state
SDEV_BLOCKED_BY_TRANSPORT.
Thanks,
Bart.
