31–40 of 178 posts
And if you use dd then you probably should specify a bigger block size than the default of 512 bytes.
But yeah, most usage is obsolete.
Author is wrong bs IS useful, try to dd one hard drive to another without reasonable bs (1-8M) with and without and you will see a difference.
Cult of pv. It looks to have more command-line complexity than dd. https://linux.die.net/man/1/pv
This is a good point as well. On BSD, we don't have `pv`, but we do have ^T. This will print some sort of status for just about any long running process. It prints very specialized status for certain programs aware of it.
Linux, not. I wonder why.
A counterpoint: dd survives not because it's good or makes sense, but explicitly because it doesn't. You wanna format a usb key? Google this, copy/paste these dd instructions, it works, move on with your life. You wanna format a usb key using something related to cat you once saw and didn't fully understand? Have fun. Both approaches have their weak points, but in any OS the answer to "How do I format a usb key" shou…
"Why do we do it like that? I dunno, that's how I learned how, how do you do it?"
Somewhat related short story: Earlier this week my friend said that he dd'd away just over 50 bitcoins, back when they were worth ~$3 each. "One of the biggest regrets of my life."
If one of the biggest the biggest lifetime regrets is a $50k financial loss, your friend is doing pretty well.
There's one good (?) reason to use dd with devices: it specifies target in the same command. For devices, writing to them usually requires root privileges, so it's easy to: sudo dd .... of=/dev/... But there's no trivial cat equivalent: sudo cat ... > target Will open target as your current user anyway. You can play around with tee and redirection of course. But that's getting more complicated than the original.
One thing I'll often use dd for is recovering data from a failing drive. Can head ignore read errors? dd can. As far as I'm concerned, dd is lower-level than most of the other utilities and provides more control over what's happening. The author does have a point that the syntax is strange though.
Use noerror, but forget sync? Corrupt output file if there is an error. Use a bigger bs so it's not slow as treacle? A single faulty sector blows away a whole bs of data, and your output image may get unwanted padding appended to the end. Recoverable error? dd's not going to retry.
Use ddrescue or FreeBSD's recoverdisk(1). They're faster, they're safer, they're more effective, and they're easier to use.
Specifiying a large block size used to help a LOT with performance. From memory shell redirection used a tiny blocksize. On Solaris at least. And if you use dd then you probably should specify a bigger block size than the default of 512 bytes. But yeah, most usage is obsolete.
so you get the best block size for reads and writes. I can't speak to what the shell does, though.
Cult of pv. It looks to have more command-line complexity than dd. https://linux.die.net/man/1/pv
This is a good point as well. On BSD, we don't have `pv`, but we do have ^T. This will print some sort of status for just about any long running process. It prints very specialized status for certain programs aware of it.