David Dillow wrote:
On Wed, 2009-10-14 at 15:47 -0700, Roland Dreier wrote:
> First it does not make sense for user to set it below 60; therefore,
> > > it is forced to have 60 and above
> > Why not? A minute seems to be a really long time given the point of
> > these patches is supposed to be failing over faster. Surely we can tell
> > if a path really failed sooner than 60 seconds on an IB fabric.
> When we fail-over, it will cause the luns ownership transfer in
> target/storage. It's undesirable op unless necessary
> Target/storage most likely can reboot and come back within 60 seconds
> We don't want to create the situation of path bouncing
OK, I can see why in some (many) situations it makes sense to wait a
while before reporting a target as gone. But why do we hard code the
policy of a minimum timeout of 60 seconds in the kernel? Why not a
minimum of 120 seconds? What if I know my storage is guaranteed to
reboot in 2 seconds -- why can't I have a timeout of 5 seconds?
You haven't really explained where the magic number of 60 seconds comes from.
On that note, does this have to be a module parameter -- what if I have
connections to different devices, that have different reboot guarantees?
It can be tuned down to target/device level instead of module parameter.
What do you think, Roland? It can be a param. in login string and stored
in target structure.
And if I really want a timeout of less than 60 seconds, why should I
have to patch my kernel?
Then target parameter would be the right approach.
And if I want to disable this completely?
Unless these patches are bad and affect the stability of the driver, why
do you want to disable it? If you don't use multipath/device-mapper and
use /dev/sd**, everything will be same
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
