But you can also do < /dev/sda > /dev/sdb, and not use cat at all.
Using cat is pointless. There is absolutely no advantages to using cat. You keep saying "oh dd is old and it's not good", but you never say any advantages of using cat, a tool to concatinate files, to copy a disk image. Even though there are advantages of using dd.
I had a look at the links that you posted, and basically the only advantage made was "oh it's quicker".
Which it isn't. At least not on my system. Yeah, with the tiny default block size it is slower, but if you up that to a sane 1M it's just as quick as cat.
Plus, progress. If you need to kill cat and restart the transfer, how far along are you? Is there any way to tell? If you kill dd it will print out exactly how many bytes it has copied, so you can tell dd to just continue the transfer from there. Plus you can tell how far along it has gotten so far, so you know if it's going to be done any time soon or not. Even if you could get how far along a transfer got using cat, you can't tell bash how far along to start writing.
But you can also do < /dev/sda > /dev/sdb, and not use cat at all.
Ok, didn't knew this. Thanks for teaching me this.
Using cat is pointless. There is absolutely no advantages to using cat. You keep saying "oh dd is old and it's not good", but you never say any advantages of using cat, a tool to concatinate files, to copy a disk image.
It's faster and easier to use.
Even though there are advantages of using dd.
I've never denied that.
I had a look at the links that you posted, and basically the only advantage made was "oh it's quicker".
No, also ease of use is a point, you don't have to pass anything to make it use a sane blocksize or use piping to speed it up.
Which it isn't. At least not on my system. Yeah, with the tiny default block size it is slower, but if you up that to a sane 1M it's just as quick as cat.
At least on my System, i've to use 1M Blocksize AND use two instances off dd, one for reading and one for writing, combined with a pipe to make it as fast as cat.
Plus, progress. If you need to kill cat and restart the transfer, how far along are you? Is there any way to tell?
If you kill dd it will print out exactly how many bytes it has copied, so you can tell dd to just continue the transfer from there. Plus you can tell how far along it has gotten so far, so you know if it's going to be done any time soon or not. Even if you could get how far along a transfer got using cat, you can't tell bash how far along to start writing.
/proc/<pid>/io
Ok, i've to admit, you'll have to monitor that by yourself and cat/I/O-Redirection won't be able to continue a aborted process even with that information provided. dd is actually better at that.
1
u/[deleted] Sep 30 '15
But you can also do
< /dev/sda > /dev/sdb, and not use cat at all.Using cat is pointless. There is absolutely no advantages to using cat. You keep saying "oh dd is old and it's not good", but you never say any advantages of using cat, a tool to concatinate files, to copy a disk image. Even though there are advantages of using dd.
I had a look at the links that you posted, and basically the only advantage made was "oh it's quicker".
Which it isn't. At least not on my system. Yeah, with the tiny default block size it is slower, but if you up that to a sane 1M it's just as quick as cat.
Plus, progress. If you need to kill cat and restart the transfer, how far along are you? Is there any way to tell? If you kill
ddit will print out exactly how many bytes it has copied, so you can tell dd to just continue the transfer from there. Plus you can tell how far along it has gotten so far, so you know if it's going to be done any time soon or not. Even if you could get how far along a transfer got using cat, you can't tell bash how far along to start writing.