DCFLDD and a Hex Editor

I sometimes use dcfldd, because it has more features and is easier to use than regular dd. It gives a constant status and updates it fast, and it also has pattern input which is a lot faster than reading from /dev/zero or any other device.

As an example, let's say I wanted to wipe a drive with dcfldd I would do something like this

dcfldd pattern="00" of=/dev/hda bs=4096

Where it would write "00000000" to the drive byte by byte and then you can use the vf= function to verify the pattern.

But I noticed a bit of a problem and wanted to know if any of you can help. When I run this

dcfldd pattern="FF" of=/dev/hda bs=4096; sync
or
dcfldd pattern="11111111" of=/dev/hda bs=4096; sync

I can fill the drive with 1's and it does so very fast. I can fill a 74gb drive to let's say 5GB worth of 1's, after it has been zeroed. If I use a hex editor like xxd or hd in linux, I can see all of the 1's.

Though if I then run this command,

dcfldd pattern="00" of=/dev/hda bs=4096; sync

Let's say for only 1gb worth of 0's, there should still be 4gb worth of 1's. Seeing that I wrote 5gb of 1's and only 1gb of 0's over the 1's.

Though if I then look at a hex editor the drive is all 0's, even if the software states it only wrote 1gb of 0's. I have tried to run the program for as short as possible sending a SIGINT almost right after running.

Any idea on why this occurs and can you replicate it?

Best Answer

What happens if you specify a count of blocks instead of manually interrupting it?

time dcfldd pattern="FF" of=/dev/hda bs=4096 count=102400; sync

then do

time dcfldd pattern="00" of=/dev/hda bs=4096 count=51200; sync

and compare the resulting times. Then look at the data on the disk to see if the boundary where ones change to zeros is where it ought to be (at about 200 Megabytes* for this example).

^{* That's real MB (1024*1024), not "maybe"-bytes.}

Related Solutions

Dd and drive imaging

For quick and dirty sort-of imaging of a Windows box, I boot a SystemRescueCD, and execute the following script (located on an external USB backup drive mounted on /mnt/backup):

 #!/bin/bash

 PCNAME=foobar # or passed in on command line if you prefer

 fdisk -l /dev/sda >./${PCNAME}-fdisk-l.txt
 dd if=/dev/sda of=./${PCNAME}-mbr.bin bs=512 count=1
 dd if=/dev/sda1 of=./${PCNAME}-p1-diag.bin bs=23040
 ntfsclone -s -o - /dev/sda2 | gzip -c | split -b 638m - ./${PCNAME}-p2-win.img.gz.

 # end

Oh, the external drive is usually formatted NTFS, mounted with "-t ntfs-3g".

Set Up Disk Cloning with dd, Netcat, and SSH Tunnel

Copying from source to target where target has sshd running:

dd if=/dev/sda | gzip | ssh root@target 'gzip -d | dd of=/dev/sda'

Copying from source to target via sshd_host when target is not running sshd.

Target: nc -l -p 62222 | dd of=/dev/sda bs=$((16 * 1024 * 1024))
Source: ssh -L 62222:target:62222 sshd_host &
Source: dd if=/dev/sda | nc -w 3 localhost 62222

dd - if= is the source, of= is the destination, bs= is the block size. Different block sizes may improve performance. 16 is usuually a fairly reasonable starting point. You can also use count= to indicate how many blocks to copy.

nc - -p indicates the port to use for services. -l is used to start a service. -w sets up the time to wait for data in the pipline before quiting.

ssh - -L sets up the tunnel on the remote host. The format of the argument is, local_port:target_host:target_port. Your local program (nc) connects to the local_port, this connection is tunneled and connected to target_port on the target_host.

The options defined are just the ones used for this. Look at the man pages for more details.

A few notes:

If you are doing this over anything but a LAN, I'd suggest compressing the datastream with gzip or compress. Bzip2 would work too but it takes a bit more CPU time. The first one has an example of that usage.
Its better if the source partition is not mounted or is mounted read-only. If not you will need to fsck the destination image.
Unless one of the machines has netcat but not ssh, netcat isn't really needed here. That case would look like:

source machine dd -> nc -> ssh -> ssh tunnel -> sshd server -> nc on target -> dd

dd works best if the source and targets are the same size. If not the target must be the bigger of the 2.
If you are using ext2/3 or xfs, dump (or xfsdump) and restore may be a better option. It wont handle the boot sector but it works when the target and source are different sizes.

Best Answer

Related Solutions

Dd and drive imaging

Set Up Disk Cloning with dd, Netcat, and SSH Tunnel

Related Topic