FUJITA Tomonori schrieb:
(...)
2) you use slow network in this configuration, as you said before?
Yes.
Slow connection is just 5 kB/s in both directions.
It's easy to reproduce the problem this way.
Slow link is the third target above.
So the connections between the target box and 192.168.4.52 are slow
while the connections between the target box and 192.168.111.173 is
not slow.
Right?
Yes, it is correct.
But I'm sure the same will happen with only one target connected (using
a slow link).
3) All your bug reports about this problem happened in this
configuration? If not, please tell me about the other configuration.
In "real life" it happens under slightly different (more complex, harder to set up) conditions:
- tgtd uses DRBD resource as the block device (backing store)
- link is about 100 kB/s (writes; DRBD replication over a slow internet connection) and fast local HDD IO (reads)
- when DRBD exchanges bitmaps with the remote peer, it suspends IO for several seconds
The problem might be related with TMF.
- more targets configured, more initiators connected
Hmm, just with lots of initiators? Even with decent link speed and no
suspended I/Os?
_And_ with DRBD and slow link.
With lots of initiators and decent speed link, no suspended IOs, it
behaves stable.
I'm not sure about what 'more targets configured' mean.
I mean that "tgtadm --op show --mode target" will output 40-50 targets.
4-5 initiators connected to each target.
But I think it's not relevant, as these segfaults don't relate to the
number of initiators or targets.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
