On 11/04/2016 05:35 PM, Martin K. Petersen wrote:
"Hannes" == Hannes Reinecke hare@suse.de writes:
Hannes> Checking with SAT-3 (section 6.2.4: Commands the SATL queues Hannes> internally) the implemented behaviour is standards conformant, Hannes> although the standard also allows for returning 'TASK SET FULL' Hannes> or 'BUSY' in these cases. Doing so would nicely solve this Hannes> issue.
I agree with Hannes that it would be appropriate for the SATL to report busy when it makes an non-queued command queueable.
Wouldn't this potentially still cause problems if the secure erase takes longer than max_retries * scmd_tmo. I.e. the command timing out by default after 180 seconds as in https://www.spinics.net/lists/linux-block/msg24837.html ?
The fix approach here seems to also handle this gracefully.
On 04/24/2018 11:09 AM, Steffen Maier wrote:
On 11/04/2016 05:35 PM, Martin K. Petersen wrote:
> "Hannes" == Hannes Reinecke hare@suse.de writes:
Hannes> Checking with SAT-3 (section 6.2.4: Commands the SATL queues Hannes> internally) the implemented behaviour is standards conformant, Hannes> although the standard also allows for returning 'TASK SET FULL' Hannes> or 'BUSY' in these cases. Doing so would nicely solve this Hannes> issue.
I agree with Hannes that it would be appropriate for the SATL to report busy when it makes an non-queued command queueable.
Wouldn't this potentially still cause problems if the secure erase takes longer than max_retries * scmd_tmo. I.e. the command timing out by default after 180 seconds as in https://www.spinics.net/lists/linux-block/msg24837.html ?
The fix approach here seems to also handle this gracefully.
Well, yes, of course the command will be terminated after it timed out. But typically secure erase is invoked from userspace via sg ioctls, and it's in the responsibility of the application to set the correct timeout.
Cheers,
Hannes
linux-stable-mirror@lists.linaro.org
-
Hannes Reinecke -
Steffen Maier