mirrors/scst
1
0
Fork 0
mirror of https://github.com/SCST-project/scst.git synced 2026-08-20 14:16:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

Commands suspending clarified

Browse Source 
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@6214 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Vladislav Bolkhovitin
2015-06-05 01:31:18 +00:00
parent 7ccc3033ec
commit 2d2621536e
3 changed files with 54 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scst/README
+25
View File
@@ -2202,6 +2202,31 @@ transfers. As the result, those threads won't receive all the processing
power of those CPUs and perform worse.
Commands suspending takes too long
----------------------------------
SCST is suspending commands during some management activities like
adding/deleting LUNs or devices. It is done to have lockless LUNs
translation on the hot commands processing path. This brings significant
performance advantage. You will see a message like "Waiting for X active
commands to complete" when this wait started.
But downside of it is that no new commands start executing until older
ones, which had started before the suspending begun, finished. This
wait can not be any longer, than the worst command latency any your
initiator is seeing at this particular time.
So, if this wait takes too long, in majority of cases it means that you
are overloading your storage. A proper storage should have worst case
latency below few hundreds of milliseconds. In this case the SCST
suspending will finish in few hundreds of milliseconds at worse.
Another case, when it can take too long to suspend is a hung user space
device (i.e. scst_user device) not responding to any command. In this
case you should kill the corresponding user space program to finish
suspending.
Work if target's backstorage or link is too slow
------------------------------------------------
scst/README_in-tree
+25
View File
@@ -1681,6 +1681,31 @@ transfers. As the result, those threads won't receive all the processing
power of those CPUs and perform worse.
Commands suspending takes too long
----------------------------------
SCST is suspending commands during some management activities like
adding/deleting LUNs or devices. It is done to have lockless LUNs
translation on the hot commands processing path. This brings significant
performance advantage. You will see a message like "Waiting for X active
commands to complete" when this wait started.
But downside of it is that no new commands start executing until older
ones, which had started before the suspending begun, finished. This
wait can not be any longer, than the worst command latency any your
initiator is seeing at this particular time.
So, if this wait takes too long, in majority of cases it means that you
are overloading your storage. A proper storage should have worst case
latency below few hundreds of milliseconds. In this case the SCST
suspending will finish in few hundreds of milliseconds at worse.
Another case, when it can take too long to suspend is a hung user space
device (i.e. scst_user device) not responding to any command. In this
case you should kill the corresponding user space program to finish
suspending.
Work if target's backstorage or link is too slow
------------------------------------------------
scst/src/scst_main.c
+4 -9
View File
@@ -894,6 +894,8 @@ static int scst_susp_wait(unsigned long timeout)
goto out;
if (res == 0) {
PRINT_INFO("%d active commands to still not completed. See "
"README for possible reasons.", scst_get_cmd_counter());
scst_trace_cmds(scst_to_syslog, &hp);
scst_trace_mcmds(scst_to_syslog, &hp);
}
@@ -975,15 +977,8 @@ int scst_suspend_activity(unsigned long timeout)
*/
if (scst_get_cmd_counter() != 0) {
PRINT_INFO("Waiting for %d active commands to complete... This "
"might take few minutes for disks or few hours for "
"tapes, if you use long executed commands, like "
"REWIND or FORMAT. In case, if you have a hung user "
"space device (i.e. made using scst_user module) not "
"responding to any commands, if might take virtually "
"forever until the corresponding user space "
"program recovers and starts responding or gets "
"killed.", scst_get_cmd_counter());
PRINT_INFO("Waiting for %d active commands to complete...",
scst_get_cmd_counter());
rep = true;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 29)