Chris Webb wrote: > Hi Mike. Many thanks for getting back to me in such detail. > > Mike Christie <[email protected]> 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,
The dm target is not dm-multipath is it? I believe dm-multipath's userspace component runs off of the hot plug events. When I discvoery iscsi or FC or SAS disks, it looks like multipthd gets run or handles a hot plug event, and then it will assemble dm-multipath devices similar to how you are trying to do it. > 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? > I was thinking you might be hitting a problem in the async code the scsi_scan.c/sd.c code use like here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=kernel/async.c;h=27235f5de198997180d4a293adc932d48c6101c7;hb=HEAD --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
