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. Thanks for all the help, Craig On Mar 26, 8:32 am, Mike Christie <micha...@cs.wisc.edu> wrote: > agspoon wrote: > > Thanks for the tip. Yes, it really is LUN-0 that is missing. All the > > other LUNs (1-6) do show up in this error condition, and upon reboot > > they all show up. It is only an occasional boot up where I see LUN-0 > > missing, and I wanted to avoid a reboot to restore it. I'll give the > > re-scan trigger a try and see if LUN-0 shows up. > > > What is the magic with the "- - -" that triggers the scan? A bit of > > It is : > > echo BUS_NUMBER TARGET_NUMBER LUN > scan > > "-" is a wild card. > > For software iscsi the first two are going to be "-" or zero (iscsi > always just uses 0), and then for LUN can you just use 0 if you are only > looking for that one. > > You can also run iscsiadm > > iscsiadm -m session -r session_id --rescan > or > iscsiadm -m session --rescan > > to scan all sessions. > > > searching shows that many other people know about this, but I've > > somehow missed it. Is there any documentation that describes this > > interface (didn't see anything in the kernel docs)? > > > Craig > > > On Mar 25, 7:27 am, Konrad Rzeszutek <kon...@virtualiron.com> wrote: > >> On Wed, Mar 25, 2009 at 08:26:46AM +0100, Ulrich Windl wrote: > > >>> On 24 Mar 2009 at 19:47, agspoon wrote: > >>>> We have an occasional problem where one LUN of a target (LUN-0) does > >>>> not appear in a connection started by iscsistart. This is in an iscsi- > >>>> root scenario where iscsistart is called from within the initrd > >>>> ramdisk image. I don't why this happens, but I can detect when it > >>>> does. However, I don't know how to stop the connection and try > >>>> again. If I just re-run iscsistart, it complains that there is > >>>> already a connection. I tried just pulling out all the iscsi related > >>>> modules and re-loading them, but they are "in use". > >>> Hi! > >>> I think that's not very iSCSI related, so my guess would be to keep the > >>> connection > >>> and try a "rescan SCSI bus" on the SCSI host/connection that you already > >>> have. > >>> Also, do you really need LUN 0? Disks are usually assigned to a LUN != 0. > >> They are with some iSCSI targets (MD3000i, DS3300, AX150, CX300, > >> Compelant, DataCore, > >> and some other ones). > > >> Do you have any other LUNs on the target except LUN-0? Do they show up? > > >> If not, you can do 'echo "- - -" > /sys/class/scsi_host/hostX/scan" to > >> retrigger the scan. That should make the LUN-0 and others show up. > > >> You will have to figure out the hostX relation to > >> /sys/class/iscsi_session/sessionY > >> yourself. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
