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: 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? 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.) Best regards, Christian -- 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.
