On 12/2/22 11:23, Eric Mackay wrote:
Greetings Heinrich and Lee,
Reaching out to both of you directly because I'm not sure that replies on the
Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982842 were
actually propagated
I made a merge request to the Debian open-iscsi package that adds this feature:
https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/14
But the maintainers don't seem to see the importance of using an iscsi root,
and/or the shortcomings of iscsistart.
Would appreciate any further comments on the bug or the merge request, as I'm
hoping to move this along. Even if they're negative comments :)
Hi All:
Sorry it took me a while to get around to replying to this.
First, responses to the bug report, i.e.:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982842
Ritesh Raj Sarraf says:
Yes. But usually, you don't need the iscsid daemon in initrd. Because
most usual cases, users would be mapping data LUNs only.
This is not my experience at all. Our distribution only supports having
root or /usr on iscsi at initrd time. If it is a "data lun" (e.g.
/usr/local or /alt) there is no reason to mount it at initrd time -- it
can wait until we have the full root filesystem up, since that's much
simpler.
he goes on to say:
Only in exceptional cases, where you have root on iSCSI, you need to
establish the connections early. And to do that we used iscsistart,
which would establish only a single connection, effectively making it
prone to hangs if that single connection went down.
Using iscsistart is a "shortcut" to having the daemon present. Many
iscsiroot users these days are using multipathing, with two independant
paths to the root disc using iscsi, and these cases get a bit
complicated for iscsistart, which is completely synchronous. For
example, iscsiadm/iscsid have the ability to send login requests but not
wait for them to return, potentially making login to slow targets (or
over slow networks) faster.
Lastly, he says:
The other reason I can recollect is that you could have a very large
number of LUNs mapped to your initiator along with your root LUN. If
you push everything to be processed in initrd:
This is not how it works in open-iscsi. Only LUNs marked as "onboot" are
handled in the initrd. Generally, LUNs marked "automatic" are brought up
when the system comes up, and LUNs marked as "manual" are only brought
up manually by the administrator.
In the bug report, Heinrich Schuchardt asked:
My current configuration is:
iscsid.conf:40:
# node.startup = automatic
nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:4:
node.startup = manual
nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:52:
node.conn[0].startup = manual
File /etc/iscsi/iscsi.initramfs specifies the root device.
HWADDR="01:02:03:04:05:06"
ISCSI_TARGET_NAME="iqn.2000-01.de.xypron:pine-a64-lts"
ISCSI_TARGET_IP="192.168.0.1"
ISCSI_TARGET_PORT="3260"
ISCSI_TARGET_GROUP="1"
ISCSI_USERNAME="user"
ISCSI_PASSWORD="password"
Where would "onboot" fit into the image?
What makes a target an "onboot" target?
Do you simply mean the one specified in /etc/iscsi/iscsi.initramfs?
Debian uses a different method than SUSE when it comes to setting up the
initrd/initramfs.
Nodes can have 3 "startup" values, as mentioned above: onboot, manual,
or automatic.
The one that matters most at runtime is "automatic", since those are the
ones that iscsi.service logs into automatically, for you, when the
system starts (if you have the service enabled).
So not having the node show up as "startup=onboot" is okay, because the
initrd knows already it is a boot iscsi target, and because iscsid will
refuse to terminate the session, since it was started from "firmware".
(But, side note: it's also helpful to set "safe_logout" in iscsid.conf
on systems with iscsi root discs.)
As far as the feature request:
https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/14
It seems fairly reasonable to me, though I'm not the one that gets to
implement this feature, if the request is accepted. :)
It seems like it does not change the default behavior, so there is
little risk of breakage.
I would be more than happy to offer advice and/or help, if needed, since
I have a special place of dislike in my heart for iscsistart.
--
Lee Duncan
open-iscsi co-maintainer
