On Tuesday, April 21, 2020 at 12:31:24 AM UTC-7, Gionatan Danti wrote: > > [reposting, as the previous one seems to be lost] > > Hi all, > I have a question regarding udev events when using iscsi disks. > > By using "udevadm monitor" I can see that events are generated when I > login and logout from an iscsi portal/resource, creating/destroying the > relative links under /dev/ > > However, I can not see anything when the remote machine simple > dies/reboots/disconnects: while "dmesg" shows the iscsi timeout expiring, I > don't see anything about a removed disk (and the links under /dev/ remains > unaltered, indeed). At the same time, when the remote machine and disk > become available again, no reconnection events happen. >
Because of the design of iSCSI, there is no way for the initiator to know the server has gone away. The only time an initiator might figure this out is when it tries to communicate with the target. This assumes we are not using some sort of directory service, like iSNS, which can send asynchronous notifications. But even then, the iSNS server would have to somehow know that the target went down. If the target crashed, that might be difficult to ascertain. So in the absence of some asynchronous notification, the initiator only knows the target is not responding if it tries to talk to that target. Normally iscsid defaults to sending periodic NO-OPs to the target every 5 seconds. So if the target goes away, the initiator usually notices, even if no regular I/O is occurring. But this is where the error recovery gets tricky, because iscsi tries to handle "lossy" connections. What if the server will be right back? Maybe it's rebooting? Maybe the cable will be plugged back in? So iscsi keeps trying to reconnect. As a matter of fact, if you stop iscsid and restart it, it sees the failed connection and retries it -- forever, by default. I actually added a configuration parameter called reopen_max, that can limit the number of retries. But there was pushback on changing the default value from 0, which is "retry forever". So what exactly do you think the system should do when a connection "goes away"? How long does it have to be gone to be considered gone for good? If the target comes back "later" should it get the same disc name? Should we retry, and if so how much before we give up? I'm interested in your views, since it seems like a non-trivial problem to me. > > I can read here that, years ago, a patch was in progress to give better > integration with udev when a device disconnects/reconnects. Did the patch > got merged? Or does the one I described above remain the expected behavior? > Can be changed? > So you're saying as soon as a bad connection is detected (perhaps by a NOOP), the device should go away? > > Thanks. > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/7f583720-8a84-4872-8d1a-5cd284295c22%40googlegroups.com.
