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
-~--~~~~--~~--~--~---