Tested on OpenBSD 7.0-current
Note: Data loss may be caused by blindly running commands in this article. Ensure the right disk is being targeted before executing anything.
It’s common (and good) advice to first overwrite a disk with random data
if it’s to be an encrypted volume. The typical suggestion is to use
dd(1) in some fashion similar to this:
# dd if=/dev/urandom of=/dev/rsd0c bs=1m
dd handles this task just fine. Certain versions of
status=progress. This isn’t the case for OpenBSD’s
SIGINFO will display the current status.
That said, there’s nothing particularly special about how
overwriting disks to my knowledge. As far as I can tell,
leveraging the power of input and output streams in a *nix environment.
Something that can be done by a tool as simple as
# cat /dev/urandom > /dev/rsd0c
Don’t mistake that as an endorsement of
cat for this job. There are
When overwriting disks with little storage capacity, the lack of
progress bar isn’t a pressing issue because the operation doesn’t take a
long time. For larger disks, an ETA proves invaluable. I like
pv for this task.
pv as a package.
# pkg_add pv
Here, I’m plugging in a flash drive for testing purposes and running
dmesg(8) for the device name.
$ dmesg [...] sd5 at scsibus6 targ 1 lun 0: <, USB DISK 3.0, PMAP> removable serial.655716319B52EBB03391 sd5: 15120MB, 512 bytes/sector, 30965760 sectors
Incidentally, this already gives us the info we need to progress forward
(number of sectors and number of bytes per sector). But, let’s check disk
for some more information.
# disklabel sd5 # /dev/rsd5c: type: SCSI disk: VOID_LIVE label: duid: 0000000000000000 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1927 total sectors: 30965760 boundstart: 0 boundend: 30965760 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 30965760 0 ISO9660 c: 30965760 0 ISO9660
One last step before overwriting: determine how many bytes total are on this disk, by multiplying the bytes/sector value by total sectors.
$ echo $((512 * 30965760)) 15854469120
Now we can overwrite the disk. We need
-s for the total amount of data
to be transferred, and
-S to stop transferring once that amount has
been transferred. Without these,
pv will display the rate of data
transfer, but not an ETA since it doesn’t know how much data it’s going
to process overall. This makes sense because
/dev/urandom will never send an “end
of file,” so we have to tell
pv when to stop.
# pv -s 15854469120 -S /dev/urandom > /dev/rsd5c 47.5MiB 0:00:02 [23.4MiB/s] [> ] 0% ETA 0:10:34
Let’s say for the sake of demonstration that I’ve made a terrible
mistake and I really needed that live disk. No problem, we can write the
data back. The image file I’m using here has already been downloaded
and cryptographically verified. The usage is simpler here, since
will detect the size of the image file and will receive an “end of
# pv void-live-x86_64-20210930.iso > /dev/rsd5c 26.5MiB 0:00:01 [26.4MiB/s] [====> ] 4% ETA 0:00:19
dd offers a level of control beyond these other tools, and is helpful
for a variety of other contexts besides writing arbitrary data to disk.
skip= are two options that come to mind for carving out
data, as well as
count= for terminating the process at a specific
dd alleviates the need to find the total number of bytes, too, since
it knows when to stop writing (mainly because
dd isn’t redirecting
STDOUT with the shell to perform writing, but rather using the
functionality baked into
dd can learn some things about the
nature of the output file that
pv won’t know due to
As an aside, it’s easy enough to pipe
dd or vice versa, but
I haven’t run into a situation where that was a necessary step.
I realize none of this is exactly groundbreaking in that this is pretty
rudimentary stuff, and only demonstrates one use case for
things are possible–creating tarballs with a progress bar, for
instance). There’s also nothing wrong with keeping it traditional and
dd. I found
pv useful when writing random data to large disks
so I could have some idea of when the process would end without any
calculation/estimation necessary on my part.