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. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
