Skip Navigation

Linux @lemmy.ml

TCB13 @lemmy.world

1y ago

Systemd Working On "Storage Target Mode" Feature - Inspired By Apple macOS

Yet another win for Systemd.

65 comments

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.
- Worked in IT, target disk mode is a life saver when you have to recover data from a laptop with a broken screen/keyboard/bad ribbon cable and don't want to take apart something held together by glue.

Soon we'll be debating whether we call it systemd/linux or gnu/systemd.
- https://www.simonwenkel.com/2020/02/03/systemd-systemd-homed-systemd-kerneld-Linux-to-Poetteringx.html
- 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!

Oh, another arm growing.

This seems like a win for almost all distros

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….?

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

Can someone eli5 pls?
- "target disk mode", which this claims to be taking a lot of inspiration from, pretty much turns your computer into an external harddrive - so you can connect another machine to it for direct access. This appears to be trying to accomplish the same, but over the network.
  If you've ever stuffed up a machine so badly that the best idea you could come up with, was to take the harddrive out and work on it from another machine - this pretty much allows you to do that. But instead of taking the drive out and putting it an external drive enclosure, you just ask the stuffed up machine to act as the external drive enclosure.
  
  Great answer
  
  Oh okay. Thanks for the simple explanation :)
- same, i have no idea what any of that means and i use runit
  
  runit gang !
  
  From what I understand it's basically like a "thin client" type of thing where the client loads the Kernel from local storage up to a certain point and then boots into a rootfs that is somewhere else on a remote server.

@TCB13 @linux Everything is systemd in the future. This has nothing to do with systemd. It could as well have been called targetdiskd.
- You assessment isn't entirely correct as this is indeed related to systemd. Read the PR https://github.com/systemd/systemd/pull/29748
  
  @TCB13 services aren't systemd-related just because they are launched by systemd.
  
  How is it related? Is there something preventing the executable from running without systemd? Just providing a service and target file doesn't mean anything if it can run without them just fine. If it came with a reference init script instead I don't think people would be arguing that it's part of sysvinit and that sysvinit is bloated.

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.

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.
  
  So when it's booted it will just advertise the storage to the LAN over nvme-tcp protocol?
  
  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?

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.

And why would this need systemd of all things? Should basically be doable over something like SSH / TFTP, right?

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

65 comments