Brand wasn't important. DLT was the information I sought.
Well cpio to and from the drive works. The command I originally gave you works to and from a file so there appears to be an issue with the way it interacts with the tape drive. Doing the dd was a way to try to get around this and you're likely running out of memory because the dd is putting all of the read into memory before piping it so that isn't the way to go.
DLT does have a hardware compression mechanism. (The 40GB is uncompressed and the 80GB is compressed.) Therefore you don't need to (and shouldn't) do compression at the software level. Software compression can actually increase the amount of data backed up.
According to the link at:
Linux defaults to enabling drive compression. Drive compression can be disabled by running mt -f /dev/tape-device compression 0. See the mt(1) man page for more info."
This means writing to /dev/nst0 IS doing it in compressed mode. (I had to look this up as on UNIX there is often a separate device for compressed and uncompressed modes. Apparently in Linux they use the same device and you need the mt command to change which way it does it.)
Also while looking I saw several comments that one can use "tar zcf ..." but then recommending AGAINST the z (or any other software compression) because if one bit gets hosed on the backup then the entire backup is useless. Specifically I saw recommendations saying not to use this on a DLT on Linux.
Given all the above I'd say you are best just piping your output into cpio as you did in your test. You'll have the best compression that way and since its at the hardware level shouldn't have the issues noted above.
Final thought - Do "ls -l /dev/nst0" to verify it is in fact a device and not a regular file:
crw-rw---- 1 root tape 9, 128 Mar 14 2002 /dev/nst0
The c at the beginning indicates its a characer (raw) device. The "9, 128" before the date is the major and minor number.
Since cpio and tar are quite happy writing to files the fact that you're able to read what you wrote doesn't prove its actually going to tape. If for some reason the device didn't exist it would just create a file by this name - you'd know because it wouldn't have a c in the first position and the number in front of the date would be a byte count without a comma.