On 2/15/21 6:48 AM, Ritesh Raj Sarraf wrote: > Control: tag -1 +help > > On Mon, 2021-02-15 at 09:46 +0100, Heinrich Schuchardt wrote: >> An upstream maintainer suggested that Debian should not use >> iscsistart >> for booting from an iSCSI volume but instead include iscsid and >> iscsiadm >> in the initrd. The same is already done in SUSE. >> >> Please, consider such a change for Debian Bookworm. > > Yes. But usually, you don't need the iscsid daemon in initrd. Because > most usual cases, users would be mapping data LUNs only. > > 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. > > But the time from when iscsistart establishes the connection and > fetched the root LUN, to the time when real init starts and the actual > iscsid daemon is run, is not a very large time. That has been the > assumption so far and the integration was built accordingly. > > 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: > > 1. The boot would be much slower, depending on how many LUNs are mapped > 2. I don't know how the initiator would behave if some of the LUNs, > from some of the targets, are temporarily unavailable. > > These days, I only work on storage as a hobby. So this feature should > be better and early co-ordinated, by users and derivatives that want to > see it follow the path. And we could definitely leverage on what Suse > has already done. >
I cannot access this bug, so I will reply to all here ... In general, you do not set up initrd to boot into all iSCSI targets, only the ones with "startup" set to "onboot". Then, later, as part of the system coming up, once the real root is established and networking is up, do you log into all "automatic" targets using open-iscsi. So the idea isn't to log into all targets at initrd time, just the same ones you log into now (i.e. "onboot" targets, needed to boot) using iscsid/iscsiadm instead of iscsistart. Note that SUSE only supports the root and /usr partitions being remote at boot time. If you have something like /opt you want to mount, it has to be done later (in our systems). I hope this clarification helps.
