Re: [libvirt] [PATCH 1/1] Add SCSI pool support.

Daniel P. Berrange wrote: >The new generic 'NewLUN' method has lost this bit of retry / sleep logic. >This unfortauntely causes us to randomly loose LUNs due to fact that >udev may not yet have created the /dev/ node or the stable path. [Forgive me if you've been through this before and I just don't know the history.] This is a race with no easy answer if udev settle does not provide the protection we need. I removed the retries because I thought udevadm settle provided the correct protection against the race, so I thought the retries only added complexity. As your example demonstrates, though, that's not enough everywhere. I can put the timeout and retry back to preserve the existing behavior, but that only makes it more likely that the path we want will win the race, it doesn't actually fix the problem. The iSCSI login should not return until the devices have appeared in the kernel, which should populate the udev queue and cause udev settle to pause until the queue clears. Is that assumption not valid everywhere? I think we need to understand why this is happening; if we have to pad the timing until the right guy wins the race, so be it, but I'd really like to understand the situation before we go there. What OS is this on? As you are, I am testing iSCSI with the IET. I have 20 LUs, and I don't see the problem. Does your system have udevadm settle?