4 ms·
I don't see how you can consider the nvme over tcp version less moving parts. dd is installed on every system, and if you don't have nc you can still use ssh a
by iforgotpassword 3y ago
I don't see how you can consider the nvme over tcp version less moving parts.
dd is installed on every system, and if you don't have nc you can still use ssh and sacrifice a bit of performance.
dd if=/dev/foo | ssh dest@bar "cat > /dev/moo"
- bayindirh 3y agoNVMe over TCP encapsulates and shows me the remote device as is. Just a block device. I just copy that block device with "dd", that's all. It's just a dumb pipe encapsulated with TCP, which is already battle tested enough. Moreover, if I have fatter pipe, I can tune dd for better performance with a single command.
- darkwater 3y agonetcat encapsulates data just the same (although in a different manner), and it's even more battle-tested. NVMe over TCP use case is to actually use the remote disk over the network as it were local. If you just need to dump a whole disk like in the article, dd+netcat (or even just netcat, as someone pointed out) will work just the same.
- iforgotpassword 3y agoNvme over TCP encapsulates the entire nvme protocol in TCP, which is way more complex than just sending the raw data. It's the opposite of "a dumb pipe encapsulated in tcp", this is what the netccat approach would be. Heck if you insist on representing the drive as a block device on the remote side you could just as well use NBD, which is just about as many moving parts as nvme over tcp but still a simpler protocol.