On Wed, 2019-04-03 at 09:06 -0700, Bart Van Assche wrote:
> 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.
(repyling to my own e-mail)
Does anyone want to share an opinion about the above?
Thanks,
Bart.
