Re: [Scst-devel] New qla2x00tgt Driver Question

[Vladislav Bolkhovitin <vst@vlnb.net>]

Dr. Greg Wettstein wrote on 12/03/2014 11:42 PM:
> On Dec 3,  8:59pm, Vladislav Bolkhovitin wrote:
> } Subject: Re: [Scst-devel] New qla2x00tgt Driver Question
> 
>> Dr. Greg Wettstein wrote on 12/03/2014 12:46 PM:
>>> Secondly, Vlad, we have been running additional testing for the last
>>> two days and we have logs from the SCST core which I am including
>>> below which suggests that the SCST core target code excessively stalls
>>> or mishandles an ABORT while processing a NEXUS_LOSS_SESS TMF.
>>> Regardless of your feelings about the target driver code in the kernel
>>> we need to make sure there is not some subtle regression in the core
>>> SCST code paths during TMF processing.
>>
>> I don't see any problem on the SCST core level in the logs.
> 
> Fair enough, thanks for taking a look.
> 
> I though it was somewhat strange to see deferred ABORT's on I/O being
> done to RAM based block devices as there is little or no I/O latency.
> In our testing, this regression always occurs on TMF function 6
> processing and this was also the case in Marc's report. The comment
> that one of the other posters made that this was secondary to slow
> backstorage didn't match the characteristics of our test environment.

For TM processing backend and frontend (target) sides are equal, so the longest side
processing is what that defines your TM processing time.

Vlad