1

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?

Dennis Williamson
  • 62,879
Recursion
  • 619

2 Answers2

1

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.

Dennis Williamson
  • 62,879
  • The first command(FF) ran in 0.52, the second command ran in 0.26.

    I then ran the following ion parentheses to scan for any 1's.

    "xxd /dev/sda | awk '$1 = " "{print}' | grep 1 > file2"

    The entire drive is now zeroed, though right before I did this I used dcfldd to write random text patterns to the drive, which were viewible by xxd. I the wrote the suggested number of 1's and followed with zero's and now the entire drive is 0's. Very very odd.

     – Recursion Dec 11 '09 at 21:53
  • There actually is some data random towards the end of the drive, from me writing text strings to it with dcfldd.

    The data occurs around this adress

    0c7ffff9

    like this 0c7ffff9 00 00 00 00 00 00 00 15 85 40 7d e4 a0 eb cc 24 |.........@}....$|

     – Recursion Dec 12 '09 at 00:29
  • I would suggest you follow up with the maintainers of dcfldd and see if there's an update or a bug they're unaware of or if they can help in some way. http://dcfldd.sourceforge.net/ – Dennis Williamson Dec 12 '09 at 00:31
  • Do you need to set the count always though? I always assumed with all dd apps, that if you don't set a count it will just write till their is nothing left to write too. – Recursion Dec 12 '09 at 08:27
  • I believe you're correct. I suggested it so there would be a predictable place to look for the boundary instead of trying to manually interrupting it. – Dennis Williamson Dec 12 '09 at 09:32
1

To get any meaningful results, unless you wish to overwrite the whole partition or disk, you need to provide a count argument. In the examples you provides, you did not specify a count. I am at a lose to understand how you ever expected to get 5gb of ones or 1gb of zeros.

fpmurphy
  • 841