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

[Sheldon T. Hall]

This is _very_ interesting.

Taking suggestions from several list members, I'm doing some speed tests to
determine how better to use my new DLT2000xt tape drives.

The machines:

	rtfm		SPARCclassic, 128 MB RAM, internal 4.5 GB HD,
			external DLT200xt on SBUS FW SE SCSI bus.

	blinky	SGI Indigo^2, R4k/200, 384 MB RAM, 2 internal
			4.5 GB HD

	tandem	SGI Chalenge L, 4xR4k/150, 1.5 GB RAM, several
			internal 18 GB SE-FW HD and internal DLT200xt
			on SE FW bus.

Currently, the drive I use is hooked to rtfm, and it doesn't stream.

Raw disk speeds
===============

Executing dd to read 2048 64k blocks (134,217,728 bytes) from a raw disk
partition and write them to /dev/null took ...

	rtfm		40 seconds
	blinky	20 seconds
	tandem	11 seconds

Raw tape speed
==============

Using the same dd command but directing the output directly to the
appropriate local tape device:

	rtfm		1:35 - mostly streamed
	blinky	no attached tape
	tandem	1:48 - can't tell about streaming, but it must not have

xfsdump speed
=============

Executing xfsdump to read 45,359,864 bytes in a filesystem on a remote
machine and write them to /dev/null on the local machine took ...

	blinky 	0:57
	tandem 	1:03

Taking the output of that same xfsdump, piping it over the network through
dd on the local machine and writing it to /dev/null took ...

	blinky to rtfm			1:18
	tandem to rtfm			1:17
	tandem to blinky			1:16
	tinkers to evers to chance	Double Play!

Conclusion
==========

As several have suggested, it looks like the SPARCclassic isn't fast enough
to stream the DLT tape from its local filesystems, even with DD.

All this was with a 10baseT network, and that looks like a limiting factor.

I'll have to do some more experimenting to see if changing the networking to
100baseT will make enough difference with the remote backups, or if moving
the backups to the Challenge will improve things.

Thanks for the ideas.  More when I know it.

-Shel