On Tue, Aug 23, 2016 at 7:25 PM, james harvey <jamespharvey20@xxxxxxxxx> wrote: > On Tue, Aug 23, 2016 at 12:00 PM, Bart Van Assche > <bart.vanassche@xxxxxxxxxxx> wrote: >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
