Re: 4.7.0 ib_srpt Regression - 4.6.4 Got failed path rec status -22 got worse on 4.7.0

On Tue, Aug 23, 2016 at 7:25 PM, james harvey [off-list ref] wrote:

On Tue, Aug 23, 2016 at 12:00 PM, Bart Van Assche
[off-list ref] wrote:

quoted

What would be ideal is to keep looping until either a timeout occurs or all
disks needed by /etc/fstab have been found. If parsing /etc/fstab is too
hard I propose to try to log in at least three times over each IB port. Even
if logging in over one IB port succeeds that doesn't mean that that is the
port to which the root disk has been connected.

I'm thinking possibly for each /sys/class/infiniband_srp/* retrying 3
times like you mention, or if it matches the sBFT's ib_source_gid
retrying many more times (100 maybe) due to the delay in being able to
use it after iPXE, which as I describe below turns out to be
interaction with opensm, and of course on a success of an
infiniband_srp not retrying that specific one anymore.  Probably only
trying ones where the ports phys_state is PortConfigurationTraining or
LinkUp.

My intention with this script was to only get new root mounted, and
allow something on the new root to handle the rest if there is any,
such as srptools, or a yet to be developed systemd service if srptools
for any reason won't work.  And, all we have at this point is the
sBFT, which the current specifications only support one set of
initiator/target port identifier, source/destination GID, service id,
and partition key.  So, if the bootloader/kernel/initrd start, the
only information we have is guaranteed to lead to the LUN with /boot.
As long as that LUN or another between the same initiator/target has
new root, we'll have that as well.

Supporting more than one target would complicate things further,
basically needing to duplicate part of srptools including an
equivalent to srp_daemon.conf.  So, I think I'll leave it at one
target.  This gives the limitation that it won't support new root
being on another target than /boot.  (Separate LUNs on the same target
is certainly OK, and is how I'm running.)  I think that's a reasonable
limitation.

Updated the github srp-boot script.

Both kernel arguments are now optional, and probably will never need
to be given.  It searches "/sys/class/infiniband_srp/*" for an entry
whose hca and port_number lead to a gids/0 that matches the sBFT's
ib_source_gid.

It waits for state to be "4: ACTIVE" before writing to add_target,
avoiding the remaining rec status -22 occurring before the SM
connection is made.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html