Date: Sat, 26 Jun 2021 17:01:45 -0600 From: John Nielsen <lists@jnielsen.net> To: freebsd-arch@freebsd.org Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: The future of the isboot (iBFT / iSCSI boot) module Message-ID: <1C9525AB-C353-41B4-9E73-587A030CCDDA@jnielsen.net> In-Reply-To: <3f821392-d6bc-126a-8ccb-b492e09995e9@FreeBSD.org> References: <97C74347-2181-4B10-A97D-823D42AFEB11@jnielsen.net> <3f821392-d6bc-126a-8ccb-b492e09995e9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 14, 2021, at 9:38 AM, John Baldwin <jhb@FreeBSD.org> wrote: >=20 > On 6/8/21 11:22 AM, John Nielsen wrote: >> [re-posted with minor edits from -scsi] >> Hi all- >> TL;DR=E2=80=94do we want to bring iSCSI boot support in to the base = system and if so, what should that look like? >> I=E2=80=99ve been maintaining (badly, at least until recently) the = net/isboot-kmod port which contains Daisuke Aoyama=E2=80=99s isboot = module. The kernel module allows a system to be booted completely via = iSCSI (no switching root, etc) from systems or NICs with native iSCSI = BIOS support or via iPXE and friends. The BIOS (or iPXE) acts as an = initiator and connects to a previously-configured target volume. Boot = (legacy or UEFI) continues normally from there=E2=80=94FreeBSD=E2=80=99s = loader can load and start the kernel, etc. What=E2=80=99s missing in the = base system is something to re-establish the iSCSI session between when = the kernel starts execution and when it tries to mount the root = filesystem. >> That=E2=80=99s where isboot comes in. Assuming the module is loaded = at boot, it will interpret the data structures in the mostly-standard = iSCSI Boot Firmware Table (iBFT) and use that information to identify = the correct NIC, bring it up, assign an IP address and gateway (if = provided), and establish an iSCSI session with the target. Once that is = done the volume is presented as a SCSI device using the CAM subsystem = and boot proceeds normally. >> The module has been around for some time (I want to say since FreeBSD = 7). I believe it was developed in tandem or for use with the net/istgt = port. I don=E2=80=99t know if it pre-dates Danny Branniss=E2=80=99 = iscsi_initiator work in base but it definitely pre-dates the = iscsid/iscsictl and ctld in base now. Upstream development on isboot has = stopped from what I can tell and the port was broken for quite some = time. I created a GitHub repo for the project and recently (with help = from several others) I updated the port to 0.2.14, which should work = with FreeBSD 1[1234]. I=E2=80=99ve made a couple more improvements and a = 0.2.15 release isn=E2=80=99t far off. See the project here if = interested: https://github.com/jnielsendotnet/isboot . >> I=E2=80=99m happy to maintain the port out of tree for the = foreseeable future but I think ideally this functionality should be = brought in to the base system. =46rom what I can tell the port has its = own complete iSCSI initiator implementation, and does not use what is = now in sys/dev/iscsi. That should probably change (and is a longer-term = goal of mine, though I will likely need help), but for now what approach = makes the most sense? >> 1) Leave it out of tree as an independent port. >> Pros: easy in the short term (nothing more to do) >> Cons: less visible to potential users, likely to suffer from bit = rot, duplicate initiator code, foot-shooting is easier with an = out-of-tree module required to mount root >> 2) Bring it in base but keep it separate from sys/dev/iscsi. >> Pros: also very easy (I=E2=80=99ve done a proof of concept to = support modules/isboot and =E2=80=9Cdevice isboot=E2=80=9D in kernel), = higher visibility, easily updated with the rest of the system (or even = linked in to the kernel directly), some defense against bit rot >> Cons: duplicate initiator code >> 3) Bring it in base, but make it depend on the sys/dev/iscsi code. >> Pros: most of the above, no duplicate initiator code >> Cons: more effort, slightly out of my depth >> 4) Bring it in base and merge it with sys/dev/iscsi. >> Pros: just one module to configure / load / worry about. Could = easily control isboot functionality via loader tunable. Makes it more of = a first class citizen. >> Cons: more effort again, probably requires broader = ownership/buy-in. >> What does the list think? Any objections or considerations I=E2=80=99m = not aware of? Any sponsorship volunteers? >=20 > I'd be a bit nervous about just going with 2) unless there's a person = lined up > to do the work of 3). The iscsi initiator and target already don't = really share > a ton of code (and possibly duplicate some things as a result). >=20 > It's also probably going to be hard to get review for a 3rd iscsi = initiator vs > something smaller that reuses sys/dev/iscsi. Good feedback, thank you. Does anyone on this list (or BCC=E2=80=99ed) = have time/interest in helping me merge the isboot initiator code with = what=E2=80=99s in sys/dev/iscsi (option 3 above)? Surely NetApp or iX want to simplify booting FreeBSD from iSCSI. :) Thanks, JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1C9525AB-C353-41B4-9E73-587A030CCDDA>