On 05/26/2015 04:14 PM, Christian Seiler wrote: > Thanks for your quick reply. > > On 05/26/2015 10:56 PM, Mike Christie wrote: >> On 5/26/15, 1:24 PM, Christian Seiler wrote: >>> 1. How stable is the socket protocol between iscsiadm and iscsid? Are >>> there any guarantuees there? Or could it happen that you upgrade and >>> then the new iscsiadm can't properly talk to the old iscsid (which is >>> needed at e.g. shutdown to log out)? >> >> It is not stable. It is assumed that when you upgrade one you upgrade the >> other. > > Thanks for confirming, that's what I suspected. > >>> 2. What I'd rather like to do is just restart iscsid (but keep the >>> currently active iSCSI sessions). From my short tests it seems to work, >>> and I observe this: >> >> Restarting iscsid is ok and is supported. > > Great, thanks, that helps a ton! > >>> - Stopping iscsid seems to be completely harmless, the TCP connections >>> of the current session remain open and storage is still acessible. >>> Obviously, if you need to react to external events and e.g. change >>> portals, that won't happen in this case (without iscsid running), >>> but for a short period of time, this should be perfectly fine. >> >> The most common problem would be if something happened to the >> connection while iscsid is down. If the network went down at this >> time, since iscsid is not up then we would not be able to relogin to >> handle the problem like we normally do. So if you were also updating >> networking packages at the same time you might want to be careful. > > Well, Debian (und probably all other distributions as well) serializes > postinstall actions of packages, so even if the network goes down while > upgrading packages (and I've never actually seen that happening), it > should be back up before iscsid is stopped. Otherwise, I would consider > that a bug of the network packages. > >> Yeah, that is correct, when iscsid restarts it restarts the >> connections/sessions. When it does this, it will block incoming IO >> until the session is restarted and will restart IO that was in >> process of executing it restarted. >> >> It will only block IO for replacement_timeout/recovery_timeout >> seconds though, so if that is really short like one or two seconds >> you could get IO errors. > > Good to know, thanks! > >>> What I want to know there is: >>> >>> - Is it safe to restart iscsid? (As long as it can log in to the >>> target again it should be, right?) Are there any side effects? >> >> It is safe. However, you probably want to check >> >> /sys/class/iscsi_session/sessionX/recovery_tmo >> >> and if it is set to a short value then temporarily increase it. Do something >> like >> >> copy /sys/class/iscsi_session/sessionX/recovery_tmo >> echo 120 > /sys/class/iscsi_session/sessionX/recovery_tmo >> kill iscsid >> Update tools and daemon >> restart iscsid >> echo original > /sys/class/iscsi_session/sessionX/recovery_tmo > > That's really helpful, thanks! I'll add something about that to > Debian's README file and add a variant of your snippet to the > postinst script for upgrades. > > Final question regarding that matter:
Sorry, I originally read this mail with my phone and missed the questions below. > > iscsid takes a while to perform recovery of sessions, but it forks off > immediately after starting. Is there a way (using e.g. iscsiadm) to > explicitly wait until recovery is complete or a timeout is reached? There is not. I need to still modify that "iscsiadm -k 0" command so that it control how quickly it kills the daemon. > > I'd like to make sure that a) no recovery is in progress before > stopping iscsid in the postinst (and fail postinst if there is still > one in progress and ask the admin to check manually) and b) after > postinst of the open-iscsi package is complete, the recovery has > already taken place. Thus I'd like to use (combining that with your > recovery_tmo setting snippet) something like > > save_recovery_timeout > wait_for_recovery || exit 1 > restart iscsid > wait_for_recovery || message "something got really screwed up, sorry" > restore_recovery_timeout > > Is that possible? (I'm basically looking for the equivalent of > udevadm settle for iSCSI sessions.) > Currently, you have to script it, so you would have to do something like iscsiadm -m session -P 1 | grep "iSCSI Connection State" and check that the state is "LOGGED IN". -- 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 open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
