cancel
Showing results for 
Search instead for 
Did you mean: 

disk wipe performance question.

SOLVED
Go to solution
Bill Costigan
Honored Contributor

disk wipe performance question.

I'm using the method that was posted on another thread to do a disk wipe.

The line that writes the zeros is:

dd if=/dev/zero of=/dev/rdsk/$1 bs=1024k

The line trhat writes ones is:
tr '\000' '\377' < /dev/zero |dd bs=1024k of=/dev/rdsk/$1

When writing the zeros I'm getting 35MB/s and each disk write is about 256KB.

When writing the ones I'm getting 2MB/s and each disk write is about 8KB.

Can someone suggest a change to the line that writes the ones which could improve its performance?

Thank you
7 REPLIES
Joachim Noffke
Occasional Advisor

Re: disk wipe performance question.

Looks like the second line is slow because all the ones need to be dynamically generated. I'd try to write them into a file of limited length first, then copy that to the target disk as many times as needed, i. e., something like this:

tr '\000' '\377' < /dev/zero | dd bs=10240k of=/tmp/onesfile count=1

i=0
while true
do
dd if=/tmp/onesfile of=/dev/rdsk/$1 bs=10240k count=1 seek=$i
if [[ $? != 0 ]]
then
break
fi
i=`expr $i + 1`
done
Dennis Handly
Acclaimed Contributor

Re: disk wipe performance question.

>Can someone suggest a change to the line that writes the ones which could improve its performance?

What happens to the timing if you use:
tr '\000' '\000' < /dev/zero | dd bs=1024k of=/dev/rdsk/$1

Note the use of a pipe will be slow. Why not write a program to do the writes with writev(2).

Or better yet use /dev/random.
Bill Costigan
Honored Contributor

Re: disk wipe performance question.

That is a good suggestion. However, I also use this method to wipe the last disk on the server (e.g. vg00)

In that case I will not have a file to read from. Perhaps a memory based file could work.

I think the issue might be the small write sizes instead of the tr command. Running Glance shows the CPU utilization low but the disk at 100% with 240 IO/sec.
Dennis Handly
Acclaimed Contributor
Solution

Re: disk wipe performance question.

>In that case I will not have a file to read from.

Where do you think the shell and dd come from?

>I think the issue might be the small write sizes instead of the tr command.

That's why changing the tr(1) parms would indicate that.
Also tusc would show you the sizes of the writes.

>Running Glance shows the CPU utilization low but the disk at 100% with 240 IO/sec.

This seems strange. I would think dd(1) would still do those 1 Mb writes.

But perhaps you need to do reblocking:
tr ... | dd ibs=8k obs=1024k of=/dev/rdsk/$1
Bill Costigan
Honored Contributor

Re: disk wipe performance question.

Dennis,

Thanks. I will try the reblocking. As for where the dd and script comes from - The last time I ran this, it appeared that everything I needed got into memory and stayed there. Perhaps the same would happen to your ones file.

Even after the vg00 disk was completely wiped the system stayed up and I could still do some commands. Of course whenever I tied to access the disk I got a filesystem error and the system failed to reboot.
Dennis Handly
Acclaimed Contributor

Re: disk wipe performance question.

>Perhaps the same would happen to your ones file.

You mean Joachim's. My write-a-C program would just use a large buffer and hopefully it would also stay in memory.
Bill Costigan
Honored Contributor

Re: disk wipe performance question.

Using the obs=1024k is at least 5 times faster.

Thank you very much.