[stgt] help tgt segfault

[Tomasz Chmielewski]

FUJITA Tomonori schrieb:

>>> Here is a lengthy log for 25 minutes - with several device 
>>> suspends/resumes.
>>> I'll give it 2 more hours testing...
>> Not 2 hours, but some observations - is it possible that tgtd serves 
>> wrong data to the initiator when the access to the media is slow?
> 
> tgtd doesn't return wrong (bogus) data.
> 
> The initiator has to give up I/O requests at some point if the target
> doesn't send responses for long time. Then you see the I/O errors.

I have the timeout set to several days, so it doesn't give up within 
single minutes. I can shut the target down for days, and the initiator 
will recover nicely when the target is back.

node.session.timeo.replacement_timeout = 1000000

And here, we had no network disconnections/malfunctions.


> Or on the target side, the kernel gives tgtd I/O errors if the backing
> store doesn't return responses for long time. Then tgtd sends the
> errors to the initiator.

No, there were no I/O errors on the target machine.
Any I/O error would be reported in dmesg; I didn't have any of such errors.


(...)

> And you see something like this in the kernel log:
> 
> sd 1:0:0:0: Device offlined - not ready after error recovery
> sd 1:0:0:0: [sdd] Unhandled error code<6>sd 1:0:0:0: [sdd] Result:
> hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
> end_request: I/O error, dev sdd, sector 0
> Buffer I/O error on device sdd, logical block 0
> Buffer I/O error on device sdd, logical block 1
> Buffer I/O error on device sdd, logical block 2
> Buffer I/O error on device sdd, logical block 3
> sd 1:0:0:0: rejecting I/O to offline device
> Buffer I/O error on device sdd, logical block 0
> 
> 
> You can replace dd with tgtd in the above example.

Exactly - you had errors in the kernel log. I didn't have anything like 
that on the machine running tgtd.
The initiator machine did have these errors, though.


-- 
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html