joshua stein <j...@jcs.org> writes: > I'm glad I could inspire you to repost the work I already did years > ago.
I'm not sure if you're being sarcastic. > But either way, if a driver is causing a panic because it responds > before it is ready, the same thing would happen without hotplug if > it was communicated with at the wrong time (like some script running > in a loop). Those drivers should just not respond to ioctls or > whatever they are doing before they are ready rather than just > hoping that no one sees their attachment too early. So the issue I have with iscsid is actually different to this because it's entirely in userland. To fix it in a robust way, you need to know when a device has attached and if it's ready or not, but there's extra requirements for iscsid that would require you to match those /dev/sd* devices back to the configured targets. At a minimum, we would need to figure out (after device attachment): a) which scsibus it has shown up on b) if the scsibus it has appeared on is indeed the one you'd expect it to be on (/dev/vscsi0 will have the same scsibus as devices initiated from iscsid, as far as I can tell) c) does the target/lun info match an initiated target with a successful session established. d) then indicate whether the disk device is actually ready There's no panic in this case, the "iscsictl reload" call in the init script returns before the devices are up and ready since we're only looking at connection completion right now. Only returning once we know there's a ready device corresponding to every connected target we expect to have one avoids the problem where fsck tries to do it's thing on devices that aren't ready. Matching back to the iscsi targets avoids some brittleness and edge cases that could be encountered if we were just looking for generic scsi disk attachments/readiness. c) is fairly easy with the diff that I submitted (and was merged) a while ago, since there is book-keeping code inside iscsid to work this out that would be very easy to extend. So the hotplug idea would solve part of this, but not all of it. There's still parts of this that are not easy and aren't clear to me how to fully resolve.
