[rescue] Block size and the single DD - more test results

[Sheldon T. Hall]

Using this script ...

#!/bin/sh
#
# Speed test for DD block-size

df -k

for bs in 8k 16k 32k 64k 128k 256k 512k
do
	echo
	echo "DD with blocksize $bs to /dev/null"
	time dd if=/dev/rdsk/c0t3d0s1 of=/dev/null bs=$bs
	echo "DD with blocksize $bs to `/usr/local/bin/what_tape`"
	time dd if=/dev/rdsk/c0t3d0s1 of=`/usr/local/bin/what_tape` bs=$bs
done

... on my SPARCclassic with a 50-pin SCSI drive on the internal SCSI
controller, and an external Compaq-branded DLT2000xt tape on the add-in SBUS
SE-FW card ...

/usr/local/bin # speedtest
Filesystem            kbytes    used   avail capacity  Mounted on
/proc                      0       0       0     0%    /proc
/dev/dsk/c0t3d0s0     246871   69232  152952    32%    /
/dev/dsk/c0t3d0s6     493705  265148  179187    60%    /usr
fd                         0       0       0     0%    /dev/fd
/dev/dsk/c0t3d0s1     122887    6470  104129     6%    /var
/dev/dsk/c0t3d0s5     246871   19082  203102     9%    /opt
/dev/dsk/c0t3d0s7    1984147 1538478  386145    80%    /users
/dev/dsk/c0t3d0s4     655273  242258  354041    41%    /usr/local
swap                  339516       8  339508     1%    /tmp

DD with blocksize 8k to /dev/null
16443+0 records in
16443+0 records out

real     1:05.4
user        0.4
sys         9.5

DD with blocksize 8k to /dev/rmt/1n
16443+0 records in
16443+0 records out

real     1:33.7
user        0.4
sys        12.1

DD with blocksize 16k to /dev/null
8221+1 records in
8221+1 records out

real       54.9
user        0.2
sys         5.1

DD with blocksize 16k to /dev/rmt/1n
8221+1 records in
8221+1 records out

real     1:12.0
user        0.4
sys         8.4

DD with blocksize 32k to /dev/null
4110+1 records in
4110+1 records out

real       55.5
user        0.1
sys         2.4

DD with blocksize 32k to /dev/rmt/1n
4110+1 records in
4110+1 records out

real     1:32.9
user        0.2
sys         4.5

DD with blocksize 64k to /dev/null
2055+1 records in
2055+1 records out

real       37.5
user        0.0
sys         1.2

DD with blocksize 64k to /dev/rmt/1n
2055+1 records in
2055+1 records out

real     1:31.9
user        0.0
sys         2.8

DD with blocksize 128k to /dev/null
1027+1 records in
1027+1 records out

real       30.1
user        0.0
sys         1.2

DD with blocksize 128k to /dev/rmt/1n
1027+1 records in
1027+1 records out

real     1:32.2
user        0.0
sys         2.5

DD with blocksize 256k to /dev/null
513+1 records in
513+1 records out

real       28.7
user        0.0
sys         0.7

DD with blocksize 256k to /dev/rmt/1n
513+1 records in
513+1 records out

real     1:29.3
user        0.0
sys         2.1

DD with blocksize 512k to /dev/null
256+1 records in
256+1 records out

real       29.1
user        0.0
sys         0.7

DD with blocksize 512k to /dev/rmt/1n
256+1 records in
256+1 records out

real     1:29.8
user        0.0
sys         2.0

......

I tried smaller blocksizes, but they were painfully slow.

Note that although using bigger and bigger block sizes speeds up the
dd>/dev/null process, the dd>tape process actually slows down once you get
bigger than 16k blocks.

It looks like the disk can reasd the /var filesystem in as little as 29
seconds, but the tape transfer process takes at least 1:12 to write that
data.  That's 64701KB/29sec = 2231 KBs reading, 64701Kb/72sec = 898 KBs
writing.  I assume a constant part of the write time is set-up and
tear-down, so the per-second speed on a larger filesystem would be higher.

It looks like a 16k blocksize is the winner as far as constant DD blocksizes
are concerned, but the DLT still wasn't streaming at that speed.

I also tried a few combinations of input and output blocksizes.  Teaming up
the fastest read size, 256k, and the fastest write size, 16k, took over two
minutes; I cancelled the job.  None of the other combinations I tried were
nearly as fast as a straight transfer with a 16k blocksize.  Evidently,
whatever time is saved by the optimal input and output blocksizes is more
than wasted by DD's having to contort itself internally.

Now that I have some benchmarks, I'll use that to do some tuning.

Of course, I actually use ufsdump to do my normal backups, so, once I figure
things out here, I still have to transfer that knowledge to the real backup
scheme ....

-Shel