On Wed, May 12, 2021 at 10:03:13AM -0400, Ashton Fagg wrote: > 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.
For iscsid I think the better approach would be to extend vscsi(4) to allow the system to know when a device was attached. Now this does not solve all problems with iscsid since iscsid has no knowledge about which disks are presented by the initator and I don't think iscsid should know about this either. -- :wq Claudio
