On 7/1/21 10:40 PM, Teemu Likonen wrote:
* 2021-07-01 20:43:09-0700, David Christensen wrote:
To "take an image", the script invokes dd(1) and pipes the output to
gzip(1), copying raw device octets to a file. To "restore an image",
the process is reversed.
Sounds like the classic "useless use of dd". For general educational
purposes I remind (not necessarily you) that "dd" is just a file copying
(and conversion) tool, almost like "cat". By default "dd" is a slow
version of "cat" because it uses smaller buffers. "dd" can be made
faster by increasing its buffer size but that will not make it more than
just "cat".
So "dd" is not a special tool for accessing device files. Device files
don't need special tools. They are files. The following command:
dd if=/dev/sdX | gzip >image.gz
is slower but functionally the same as either of these:
gzip </dev/sdX >image.gz
gzip --to-stdout /dev/sdX >image.gz
Usually we don't need "dd" for anything but there are some options which
are useful sometimes. For example, "dd" can report progress to standard
error stream and it can seek and limit read to some blocks or bytes.
My description was a high-level overview. As always, "the devil is in
the details". dd(1) has features that would require extra work with
cat(1) or gzip(1). The script provides all of the options to dd(1) that
you mention, and more. 'bs=1048576' gives good performance, makes math
easy, and dovetails with 'parted ... u MiB'. I also omitted
functionality like MD5 and SHA256 checksum files, byte-for-byte
verification, Bash code generation from Perl, and opportunities for
concurrency (yet to be implemented). It's all good stuff that you
encounter when you've been doing imaging by hand and decide to "up your
game" with scripting.
David
