81–90 of 181 posts
I just take my nvme drive out of the last one and I put it into the new one.
I don't even lose my browser session.
Edit: If you do this (and you should) you should configure predictable network adapter names (wlan0,eth0).
Earlier quoted context omitted.
Did it ‘just work’? Serious question since last time I tried a direct non-Ethernet connection was sometime in the 90s ;)
I assume that those USB-C connectors were USB 4 or Thunderbolt, not USB 3. With Thunderbolt and operating systems that support Ethernet over Thunderbolt, a virtual network adapter is automatically configured for any Thunderbolt connector, so connecting a USB C cable between 2 such computers should just work, as if they had Ethernet 10 Gb/s connectors. With USB 3 USB C connectors, you must use USB network adapters (up…
It's very useful for sending large data using minimal equipment. No need for two cat6 cables and a router for example.
In the author's scenario, there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O. All the complex commands can be replaced by a simple netcat. On the destination laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M On the source laptop: $ nc x.x.x.x 1234 The dd on the destination is just to buffer writes so they are faster/more efficient…
A lot of hassle compared to: nbdkit file /dev/nvme0n1 nbdcopy nbd://otherlaptop localfile
I recently had to copy around 200gb of files over wifi. I used rsync to make sure a connection failure doesn't mean I have to start over and so that nothing is lost, but it took at least 6 hours. I wonder what could I have done better. Btw, what kinds of guarantees do you get with the dd method? Do you have to compare md5s of the resulting block level devices after?
In the author's scenario, there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O. All the complex commands can be replaced by a simple netcat. On the destination laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M On the source laptop: $ nc x.x.x.x 1234 The dd on the destination is just to buffer writes so they are faster/more efficient…
> there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O I guess most people don't have faster local network than an SSD can transfer. I wonder though, for those people who do, does a concurrent I/O block device replicator tool exist? Btw, you might want also use pv in the pipeline to see an ETA, although it might have a small impact o…
In the author's scenario, there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O. All the complex commands can be replaced by a simple netcat. On the destination laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M On the source laptop: $ nc x.x.x.x 1234 The dd on the destination is just to buffer writes so they are faster/more efficient…
Aside, I guess nvme-tcp would result in less writes as you only copy files in stead of writing the whole disk over?
Earlier quoted context omitted.
Yeah, I've done several such transplants of disks onto different hardware.. maybe even from an AMD to an Intel system once (different mainboard chipsets), and of Windows 7. As you say, it will say new hardware detected and a lot of the times will get the drivers for them from Windows Update. There are also 3rd party tools to remove no-longer existing devices from the registry, to clean the system up a bit.
Windows will, however, no longer acknowledge your license key. At least that is what happened when I swapped a Windows installation from an Intel system into an AMD system.
In the author's scenario, there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O. All the complex commands can be replaced by a simple netcat. On the destination laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M On the source laptop: $ nc x.x.x.x 1234 The dd on the destination is just to buffer writes so they are faster/more efficient…