]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
scsi: core: Handle depopulation and restoration in progress
authorDouglas Gilbert <dgilbert@interlog.com>
Sun, 15 Oct 2023 05:06:50 +0000 (01:06 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 7 Mar 2025 15:56:31 +0000 (16:56 +0100)
commit79a43ee6ec0d71ff64c9ec98f73caf5dd35a1a32
tree1c7654055ad13287b81fec6225b0320ed5c6cc56
parent5c1e84bc75a6610576c8faec840b0aa839a50175
scsi: core: Handle depopulation and restoration in progress

[ Upstream commit 2bbeb8d12404cf0603f513fc33269ef9abfbb396 ]

The default handling of the NOT READY sense key is to wait for the device
to become ready. The "wait" is assumed to be relatively short. However
there is a sub-class of NOT READY that have the "... in progress" phrase in
their additional sense code and these can take much longer.  Following on
from commit 505aa4b6a883 ("scsi: sd: Defer spinning up drive while SANITIZE
is in progress") we now have element depopulation and restoration that can
take a long time.  For example, over 24 hours for a 20 TB, 7200 rpm hard
disk to depopulate 1 of its 20 elements.

Add handling of ASC/ASCQ: 0x4,0x24 (depopulation in progress)
and ASC/ASCQ: 0x4,0x25 (depopulation restoration in progress)
to sd.c . The scsi_lib.c has incomplete handling of these
two messages, so complete it.

Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20231015050650.131145-1-dgilbert@interlog.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stable-dep-of: 9ff7c383b8ac ("scsi: core: Do not retry I/Os during depopulation")
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/scsi/scsi_lib.c
drivers/scsi/sd.c