>>> Donald Williams <[email protected]> schrieb am 21.04.2020 um 20:49 in Nachricht <30147_1587494977_5E9F4041_30147_801_1_CAK3e-EawwxYGb3Gw74+P-yBmrnE0ktOL=Fj1OT_L [email protected]>: > 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
Actually I think that's two different mechanisms: Keepalive just prevents the connection from being discarded (some firewall like to do that), while the No_op actually is an end-to-end (almost at least) connection test. > 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. I think the original intention for SCSI timeouts was to conclude a device has failed if it does not respond within time (actually there are different timeouts depending on the operation (like the famous rewinding of a long tape)). Next step for the OS would be to block I/O to a seemingly failed device. Recent operating systems like Linux have the choice to remove the device logically, requiring it to re-appear before it can be used. In some cases it seems preferrable to keep the device, because otherwise there could be a cascading effect like killing processes that have the device open (UNIX processes do not like it when opened devices suddenly disappear). Regards, Ulrich > > 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-5cd28429 > 5c22%40googlegroups.com >> > <https://groups.google.com/d/msgid/open-iscsi/7f583720-8a84-4872-8d1a-5cd28429 > > 5c22%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-yBmrnE0k > tOL%3DFj1OT_LEQ%2BCZyZUkg%40mail.gmail.com. -- 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/5E9FEC8E020000A1000387D7%40gwsmtp.uni-regensburg.de.
