Hello, If the loss exceeds the timeout value yes. If the 'drive' doesn't come back in 30 to 60 seconds it's not likely a transitory event like a cable pull.
NOOP-IN and NOOP-OUT are also know as KeepAlive. That's when the connection is up but the target or initiator isn't responding. If those timeout the connection will be dropped and a new connection attempt made. Don On Tue, Apr 21, 2020 at 2:44 PM The Lee-Man <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/open-iscsi/7f583720-8a84-4872-8d1a-5cd284295c22%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAK3e-EawwxYGb3Gw74%2BP-yBmrnE0ktOL%3DFj1OT_LEQ%2BCZyZUkg%40mail.gmail.com.
