On 5/26/15, 1:24 PM, Christian Seiler wrote:
Hi there,
I want to improve open-iscsi packaging in Debian and I've stumbled upon
the question of what to do on package upgrades. Currently, Debian's
package doesn't do anything on upgrades, i.e. the old iscsid is left
running. (The current documentation in Debian is misleading when it
comes to updates btw.)
I have a couple of questions about that:
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.
But even if the protocol is guaranteed to be stable: is that a good
idea? In principle, there could be security upgrades in the future,
where you'd want to restart iscsid... which leads to:
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. It is how many distros do boot
when going from the initramfs to the real root.
- 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.
- Starting iscsid again, it will close the current TCP connections for
the sessions, reconnect to the portal and then use that. It also
says 'connection1:0 is operational after recovery (1 attempts)',
although that typically takes a couple of seconds after it started.
I didn't notice any trouble with the storage, filesystems reamined
mounted, no kernel messages (even active I/O would continue,
blocking only for a very short amount of time).
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.
- Also, with root on iSCSI, you typically have the configuration:
initramfs uses iscsistart to log in initially, then when the system
comes up properly iscsid is started for the first time. So there you
already have the case that iscsid is regularily started with already
active iSCSI sessions.
Yeah.
On the other hand, I don't have any weird corner-case configurations
here (my test system is in fact a VM that connects to a software
target), so I can't test any really weird setups.
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
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
