agspoon wrote:
> Thanks for the explanation.
> The rescan seemed to do the trick.  I added it to the boot logic, and
> caught a blade with this error just yesterday.  There are 9 LUNs, but
> when this happens it is always LUN-0 that is missing.  A "- - -"
> rescan found the missing LUN and created the new device (/dev/sdi).
> The target is some funky custom box that no one else in the world
> uses ;)
> The iscsistart utility returns success, and creates a single session
> with multiple LUNs.  The first one is occasionally missing (say 1 in
> 25 reboots).
> I was wondering if our boot script is not waiting long enough between
> loading the iscsi kernel modules, and running iscsistart.  I might
> play with sleeping for a second between loading the last module, and
> trying to make the connection.  Just in case it is a race condition.

The time between loading the kernel modules and running iscsistart 
should not be an issue. iscsistart has a built in wait. It will log into 
the target, then it actually does the same command

echo "- - -"  > /sys.../scan

(it does this by doing a write() instead of calling echo).

That command then does not return until the scanning is done from the 
kernel perspective.

However, what could happen is that if /dev/sdX was getting created by 
something like udev as a result of a hotplug event you might need a 
wait/sleep in there. The kernel will scan and setup the deivce 
intnernally then send a hot plug event and then return from the "echo - 
- - ... scan". Userspace apps can then listen for the event and setup 
the /dev/sdX node. I think for startup/boot though udev does not just 
listen for hotplug events incase something like this were to happen. I 
have no idea though :)

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to