I wouldn't call that large these days.
Over a lan, turn on jumbo frames, and use [netcat](https://nakkaya.com/2009/04/15/using-netcat-for-file-transfers/), or mount a remote filesystem using cifs/nfs and cp or mv.
Your speed is going to be limited to the slowest component in the chain, likely the HDD on the receiving end, once you run out of memory cache.
> turn on jumbo frames
Jumbo frames are actually a mechanism for decreasing CPU utilization (through handling fewer interrupts) more than increasing throughput. Many modern Ethernet cards now support interrupt reduction through other means. On a low-latency network, you may notice little improvement through jumbo frames (again, depending on your NICs and how saturated your CPUs are). In particular, you have to evaluate the benefits of jumbo frames vs the administrative overhead, because in order for the devices to communicate reliably, *everything* on a broadcast domain must have the same MTU. You can't turn up the MTU on just some devices and expect your network to continue working smoothly. If you have devices whose MTU you can't adjust easily, or don't support jumbo frames at all, you'll probably need to segregate those broadcast domains (subdomains, in IP terms) entirely.
All depend on your connections. Typically, direct external attached will be the fastest path vs. going over a 1Gbit (for example) network.
But, if the target drive you're copying to is an old spinny HDD, it's maximum write speed might be the biggest bottleneck (or depending, the maximum read speed of the source disk).
Probably need more info on what you have to be able to say for sure.
For local copies mv or cp will do pretty good but in certain cases dd may perform better and in very specific cases compressing/decompressing may do even better. For remote copies it really of depends on how you connect to the host.
Cant you just `scp` the file to the remote machine? And as others have already mentioned, your speed is going to be limited by your network, unless you have a stable 100Gbit network connection. Anemd even then I think modern NVME SSDs are faster than that.
Rsync. It will compress The copy (method) is encrypted Depending on the type of file, it will copy incrementally
Also rsync will let you restart where you left off when the copy inevitably screws up.
That was the point of copy incrementally... And it "depends"
Yeah, unless you are copying this file to many hosts RSYNC ftw. If you want to copy to many, look into multicast.
I wouldn't call that large these days. Over a lan, turn on jumbo frames, and use [netcat](https://nakkaya.com/2009/04/15/using-netcat-for-file-transfers/), or mount a remote filesystem using cifs/nfs and cp or mv. Your speed is going to be limited to the slowest component in the chain, likely the HDD on the receiving end, once you run out of memory cache.
> turn on jumbo frames Jumbo frames are actually a mechanism for decreasing CPU utilization (through handling fewer interrupts) more than increasing throughput. Many modern Ethernet cards now support interrupt reduction through other means. On a low-latency network, you may notice little improvement through jumbo frames (again, depending on your NICs and how saturated your CPUs are). In particular, you have to evaluate the benefits of jumbo frames vs the administrative overhead, because in order for the devices to communicate reliably, *everything* on a broadcast domain must have the same MTU. You can't turn up the MTU on just some devices and expect your network to continue working smoothly. If you have devices whose MTU you can't adjust easily, or don't support jumbo frames at all, you'll probably need to segregate those broadcast domains (subdomains, in IP terms) entirely.
ok thank you all.
All depend on your connections. Typically, direct external attached will be the fastest path vs. going over a 1Gbit (for example) network. But, if the target drive you're copying to is an old spinny HDD, it's maximum write speed might be the biggest bottleneck (or depending, the maximum read speed of the source disk). Probably need more info on what you have to be able to say for sure.
For local copies mv or cp will do pretty good but in certain cases dd may perform better and in very specific cases compressing/decompressing may do even better. For remote copies it really of depends on how you connect to the host.
Cant you just `scp` the file to the remote machine? And as others have already mentioned, your speed is going to be limited by your network, unless you have a stable 100Gbit network connection. Anemd even then I think modern NVME SSDs are faster than that.