Re: [Scst-devel] SCST suspend race against several incoming commands that are BUSY'd out

[Bart V. A. <bar...@sa...>]

On 05/01/15 12:28, Shyam Kaushik wrote:
> We are using SCST 2.2.1 to expose ~200 LUNs to ~200 initiators. Some LUNs
> are exposed to multiple initiators(~10-15), while others are to one
> initiator. Periodically we add/remove LUN exposure to initiators based on
> needs.
>
> As part of the add/remove LUN exposure to initiator, SCST does the global
> suspend/resume. This typically completes in a short-while (like 1-2 secs)
> but periodically we see that SCST suspend takes 1-minute or higher. During
> this entire period all new IOs are rejected with BUSY/QUEUE_FULL. We have
> confirmed that we don't have any backend-side issues to complete the
> in-progress IO's (they complete very fast in our environment). We have
> logging below SCST to capture IO times & don't see any issue in terms of
> speedy completion of IO's.

Hello Shyam,

Thanks for the detailed report. It would be appreciated if you could 
repeat your test with the code on the master branch of 
https://github.com/bvanassche/scst. Compared to last week, the following 
has changed in the code on that branch:
* iSER target support has been added.
* Adding and removing LUNs occurs now without suspending I/O and without
   any degradation in I/O performance. This is a feature many SCST users
   have been asking for since a long time.

Thanks,

Bart.