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 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.

Reply via email to