Hello Re: Errors That's likely from a bad / copy paste. I referenced the source document I took that from. That was done against an older RHEL kernel.
Don On Wed, Apr 22, 2020 at 3:04 AM Ulrich Windl < [email protected]> wrote: > >>> 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 > . > -- 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-EbBaqnn89HTJ4D8beY9KGCJ_jYwFXOFgR4qW59QPn0DFQ%40mail.gmail.com.
