On 11/12/12 23:40, Or Gerlitz wrote:
> Bart Van Assche <[email protected]> wrote:
>> This patch is a modified version of a patch from Karandeep Chahal
>> that was posted on May 29, 2012 on the linux-rdma mailing list
>> (http://www.mail-archive.com/[email protected]/msg11796.html)
>
> If you want your patch to land upstream, I would expect here a
> change-log that explains why we want to do that... e.g what happens if
> someone mounts a file system on this block device, do we want to pull
> the rug behind the FS legs, why? what's special in port down even from
> any other loss of IB connectivity that we have to give it special
> treatment? why its needed to react on IB events and not just on
> connectivity loss?
This patch is not an essential part of this patch series. All it does
is to trigger failover more quickly if a port down event has been
received. Without this patch, if an IB cable has been disconnected long
enough, a QP error will be generated anyway and that event will trigger
the path failure logic introduced in the earlier patches of this series.
Regarding file system behavior: if a file system should be shielded
from path failures in a multipath setup then it should be mounted on
top of a multipath device instead of using the SCSI host directly
created by ib_srp. In the file system tests I ran I have been using
the following multipathd options:
defaults {
queue_without_daemon no
}
devices {
device {
...
features "3 queue_if_no_path pg_init_retries 50"
fast_io_fail_tmo 15
dev_loss_tmo 60
}
}
Are you perhaps worrying about what will happen in a setup with a single
path between initiator and target and where the IB connection disappears
and reappears quickly ? Shouldn't multipath be used even in such a setup
to avoid that the filesystem encounters an I/O error if the path disappears
for a longer time than what is tolerated by the SCSI error handler in order
to recover gracefully ?
Thanks,
Bart.
--
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
