Yet another win for Systemd.
Target disk mode is fantastic, I’m thrilled to see this coming to Linux
It’s a nice feature. I used it a few times on old Macs with external FireWire hard drives for booting a different OS or troubleshooting.
deleted by creator
Red Hat: “we put the D in your System”
I’m happy that this is coming to linux (I believe Nutanix has a great method to expose storage over IPs), but I would have liked if this was a bit more project/dependence agnostic.
I mean, it specifically is giving support for booting disks over an existing protocol to systemd. That’s pretty well within scope?
Oh, my gripe is not with Poettering creating a systemd service for it (for I cannot dispute that systemd wrappers such as this does make life somewhat easier), but I would have liked perhaps a more distribution agnostic method of running NVMe-TCP in a way that the OS would not have to be booted. I suppose I do understand the community’s support for this: systemd is used by most of the popular distributions, and writing a service in it will enable systemd to maybe interleave this between other processes and perhaps fulfill the goal of producing a block device on an L3 network without booting userland.
As one can probably surmise, I do not have a great understanding of how the process works - will have to figure out how MacOS did it first, and then about how Poettering implemented it. I think I’ll have a better idea of what the solution is geared towards.
Thanks for your comment!
I would have liked perhaps a more distribution agnostic method of running NVMe-TCP in a way that the OS would not have to be booted.
From the pull request:
This all requires that the target mode stuff is included in the initrd of course. And the system will the stay in the initrd forever.
I think that’s as minimal a boot target as you can reasonably get, or in other words you’re as far away from booting the OS as you can get.
So now the question is whether this uses any systemd-specific interfaces beyond the .service and .target files. If not, it should not take much effort to create a wrapper init script for the executable and run it on non systemd distros.
Thanks, that makes it easy to understand. Indeed, it doesn’t seem very dependent on systemd, which is great. I was aware that the project existed, and for a second thought that Poettering was trying to integrate it directly within systemd somehow whilst making improvements to it. I suppose that’s not the case, which is good.
And you’re correct, that is probably the easiest way to boot the minimum required resources.
Thanks.
“Magic was meant to serve men, never to rule over them.”
Pragmatism > all else.
Link to the post (for accessibility and follow-up in the thread): https://mastodon.social/@pid_eins/111324093735348164
Pull request: https://github.com/systemd/systemd/pull/29748
Yay, yet another storage protocol over the network.
Not a storage protocol over the network, but yes :P
“ via NVMe-TCP (in case you wonder what that is: it’s the new hot shit for exposing block devices over the network, kinda like iSCSI…”
So….?
The protocol already existed. This made it convenient to boot from it
So NVMe-TCP is yet another storage over network standard…. Regardless of making it work like this.
I guess if you had your way we’d still be doing token ring over twin-ax. Whatever
I see no flaw in this logic
This seems like a win for almost all distros
Is this like booting over pxe? Is nvme tcp widely supported on motherboards?
No, this has nothing to do with your motherboard. Once you reach the boot menu you’ll be able to pick your OS and alternatively
systemd-storagetm. If you chose the the latter then your disks will be available to other machines over NVME-TCP. Just like Apple.The problem of keeping comparing and doing analogies with apple shit stuff is that many of us have no idea what tech of magic apple does, so saying things like “just like apple” is a completely useless phrase that gives zero info whatsoever about anything.
So I could mount and chroot over TCP to fix problems? Looks a little more complicated at this point than fstabbing an iscsi target, but I imagine that’ll improve. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_storage_devices/configuring-nvme-over-fabrics-using-nvme-tcp_managing-storage-devices
Sweet.
The PR aims to make it easy and simple.
So like, grubd boot menu? And from there I can boot over a location on my nas for example? I set up ipxe a couple weeks ago but it couldn’t load over my thunderbolt to 10g nic. Would this help?
How do you think file systems would be handled? Apple’s SCSI/FireWire/USB/Thunderbolt Target Disk Mode just made all disks available over the interface in a filesystem-agnostic manner. Would I be able to see my ext4 boot partition, ZFS arrays, and any attached volumes?
As with Apple’s implementation, filesystems aren’t handled - whatever device you connected with would see block devices, essentially no different from a physical disk in your system.
So this is a service aimed at exposing disks as nvme-tcp boot targets on boot of the system? I mean I love it, I wonder if this could be used to help with a chicken and egg problem I’ve had with building clustered systems easier. So far I either need a running service to host a network file system (like NFS or CEPH), or I need local disks that bootstrap the clustered storage environment.
Not compelling to me. Gonna stick with runit and/or s6 on my Artix Linux systems at home. But you do you Lennart.
Same for me, but dinit
