Dump/Tape block question

Gary W. Swearingen garys at opusnet.com
Mon Jul 25 14:52:59 GMT 2005


FreeBSD Questions <ml.freebsd.questions at gmail.com> writes:

> How big is each block?  I'd like to know about where on the tape I am
> when I do an 'mt rdhpos' command (but I don't know how to determine
> the reported block size), and I'd like to be able to calculate how
> much data was written for each backup based on the number of blocks
> dumped (I assume these blocks are the size I specify on the dump
> command line).  In fact, how can I calculate how many blocks my tape
> can hold?  (i.e. What is the biggest block number an 'mt rdhpos' or
> 'mt rdspos' will report for my tape?)

It'd be real useful to have some "intro to tapes and blocks", huh?
I recently did some testing on my DDS-II drive to try to figure it
out, somewhat.

You needn't go to the end of the tape to figure the "tape block size";
take the number of bytes written and divide by the rdhpos number.

If I "cat" to the drive, the tape records seem to be 4096 bytes.

If I use "dd", the tape records seem to be the "bs" size.

The "rdspos" and "rdhpos" are almost the same, with "rdspos" probably 
counting an extra block for each "file mark".

Those "rdxpos" counts for a given file are the same whether tape-drive
compression is on or off, meaning that with compression on, you can't
well-predict what the "rdhpos" would be at the end of the tape, or
what percentage of the tape you've used. :(

I didn't try "tar" blocking, though the new "f" tar works fine to
a disk file or piped to another tar.

Backup duration (on my fast sys, anyway) is determined by how much
tape is used, not on whether drive or CPU has to do on-the-fly
compression or not.  Except that (based on one test) it seemed to
take the drive longer to write a compressed file with compression
on, than with compression off.  So I'll be compressing on the CPU
and turning drive compression off (which has the side benefit of
giving more useful "rdhpos" numbers).

Suggestion: write an "mt" command that intercepts "mt erase" without a
"0" argument, if you don't want to wait an hour or more for the tape
to be fully erased. (You can't even kill -9 "mt".)


More information about the freebsd-questions mailing list