On Sat, Dec 24, 2011 at 8:07 PM, David Dillow dillo...@ornl.gov wrote:
This says to me that SRP should use the dev_loss_tmo semantics, though
the naming of fast_io_fail vs replacement_timeout is a bit more of a
question than I thought. I tend to think of SRP more in terms of FC than
iSCSI, so
On Fri, Dec 23, 2011 at 10:56 PM, Mike Christie micha...@cs.wisc.edu wrote:
iSCSI replacement_timeout is the same as fast_io_fail_tmo for FC. iSCSI
replacement_timeout actually came first so you should say FC should have
copied our name :)
Agreed. But as far as I can see multipathd only
On Fri, 2011-12-23 at 16:56 -0600, Mike Christie wrote:
On 12/23/2011 04:34 PM, David Dillow wrote:
We should match the rest of the SCSI stack unless there is good reason
to go our own way. The iSCSI transport can do what it does because it
has a native ping, but I'm not convinced they
On Wed, 2011-12-21 at 14:07 +, Bart Van Assche wrote:
On Wed, Dec 21, 2011 at 3:05 AM, David Dillow dillo...@ornl.gov wrote:
We don't want to leave a target blocked indefinitely -- commands caught
in the blocked queue won't be reissued until the queue is unblocked --
but we may want to
On 12/23/2011 04:34 PM, David Dillow wrote:
On Wed, 2011-12-21 at 14:07 +, Bart Van Assche wrote:
On Wed, Dec 21, 2011 at 3:05 AM, David Dillow dillo...@ornl.gov wrote:
We don't want to leave a target blocked indefinitely -- commands caught
in the blocked queue won't be reissued until the
On Wed, Dec 21, 2011 at 3:05 AM, David Dillow dillo...@ornl.gov wrote:
We don't want to leave a target blocked indefinitely -- commands caught
in the blocked queue won't be reissued until the queue is unblocked --
but we may want to keep the sdX mappings around for a long time.
On Mon, Dec 19, 2011 at 10:32 PM, David Dillow dillo...@ornl.gov wrote:
I still think this is already solved in user space, but the new
reconnect model you've implemented doesn't match up with the expected
semantics. It'd be better to match the rest of the SCSI stack for this.
Sorry, but I'm
On Mon, Dec 19, 2011 at 10:32 PM, David Dillow dillo...@ornl.gov wrote:
Part of the problem is introduced by allowing for permanent connections
rather than using the familiar dev_loss_tmo and fast_io_fail_tmo
parameters from other SCSI transports. For instance, in the FC
transport, rports are
On Tue, 2011-12-20 at 10:13 +, Bart Van Assche wrote:
On Mon, Dec 19, 2011 at 10:32 PM, David Dillow dillo...@ornl.gov wrote:
I still think this is already solved in user space, but the new
reconnect model you've implemented doesn't match up with the expected
semantics. It'd be better
On Tue, 2011-12-20 at 10:27 +, Bart Van Assche wrote:
On Mon, Dec 19, 2011 at 10:32 PM, David Dillow dillo...@ornl.gov wrote:
Part of the problem is introduced by allowing for permanent connections
rather than using the familiar dev_loss_tmo and fast_io_fail_tmo
parameters from other
On Mon, Dec 19, 2011 at 12:50 AM, David Dillow dillo...@ornl.gov wrote:
On Thu, 2011-12-01 at 20:11 +0100, Bart Van Assche wrote:
Add a time-based transport layer test such that fail-over in a multipath
setup can happen quickly.
Why should this be done in the kernel? multipathd already
On Mon, 2011-12-19 at 05:16 -0500, Bart Van Assche wrote:
On Mon, Dec 19, 2011 at 12:50 AM, David Dillow dillo...@ornl.gov wrote:
On Thu, 2011-12-01 at 20:11 +0100, Bart Van Assche wrote:
Add a time-based transport layer test such that fail-over in a multipath
setup can happen quickly.
On Thu, 2011-12-01 at 20:11 +0100, Bart Van Assche wrote:
Add a time-based transport layer test such that fail-over in a multipath
setup can happen quickly.
Why should this be done in the kernel? multipathd already verifies all
paths to a SCSI device are up and that the device is reachable.
--
Add a time-based transport layer test such that fail-over in a multipath
setup can happen quickly.
Add the necessary functions in the SRP transport module to allow an SRP
initiator driver to implement this.
Add a slave_delete callback in the SCSI host template such that SCSI
hosts that hold a
14 matches
Mail list logo
