Hi Mike. Many thanks for getting back to me in such detail.

Mike Christie <micha...@cs.wisc.edu> writes:

> On 08/06/2009 02:32 PM, Chris Webb wrote:
[...]
> > What's the canonical race-free way to wait for the iscsi login to properly
> > finish and the device node to be available? At the moment, I have a hack
> 
> I am not sure about that. I will just add some details about what 
> iscsiadm is doing.
>
> After it logs into the target it does
> 
> echo - - -  > /sys/class/scsi_host/hostX/scan
> 
> This has the scsi layer do commands like inquirys and report luns to 
> find your disks. The scsi layer will then create the kernel structs for 
> the scsi devices and when that happens it will fire hot plug events that 
> udev waits for. When the kernel setup is done the echo command above 
> will return.
> 
> So from iscsiadm's perspective it has logged in and detected the disks. 
> It has no idea udev is running or not. Maybe in some cases like when run 
> from the initrd/initramfs udev might not be running like normal.
> 
> If you add a udev rule, that checks for iscsi devices and does whatever 
> you were trying to do will that help?

To be honest, I don't really need udev to have completed, but I'm using it
finishing as an indicator that I can safely scan /sys/ for the new iscsi
device and start using it in a device mapper target. From what you describe,
iscsiadm exiting ought to be completely sufficient for this, and a udevadm
settle on its own should be enough to guarantee the /dev/sdX node.

What I'm doing is fairly heavyweight (building device mapper tables and then
starting qemu-kvm virtual machines) and potentially depends on a number of
different iscsi logins, so I can't reasonably do it in a udev rule. However,
I could have a custom udev rule to produce a symlink by target name for the
device node, and do something like

  udevadm settle
  until [ -f /dev/my/symlink ]; do sleep 0.1; done

and read the major/minor from (the target of) the symlink rather than
searching sysfs myself; maybe that would be a bit tidier.

> For the problems below, I am not sure what is up. The iscsi code has no
> control over it. I think the first problem is fixed though. I think there
> were some bugs in the kernel async scanning code (can you turn that off in
> the kernel configuration) that were fixed recently in 2.6.31-rc5.

Sure, I can turn off the async bus scanning. It's not something we really
make use of other than the convenience of slightly faster boot times. Don't
suppose there's an easy way to disable this without rebooting the machine?

Out of curiousity, and wondering about a back-port, I've been looking for
the bug-fix commit you mention, but haven't turned it up yet. I found Edward
Goggin's patch initialising max_target_blocked in scsi_alloc_target() but
that's already in the 2.6.30.4 stable tree that I'm using. I don't see any
more recent changes in scsi_scan.c apart from the increased INQUIRY timeout.
Were the patches elsewere in the kernel?

Cheers,

Chris.

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

Reply via email to