Date: Mon, 25 Jul 2005 07:53:29 -0700 From: garys@opusnet.com (Gary W. Swearingen) To: FreeBSD Questions <ml.freebsd.questions@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Dump/Tape block question Message-ID: <iju0ijkkd2.0ij@mail.opusnet.com> In-Reply-To: <10549b08050725052035362ea8@mail.gmail.com> (FreeBSD Questions's message of "Mon, 25 Jul 2005 08:20:14 -0400") References: <10549b08050725052035362ea8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD Questions <ml.freebsd.questions@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".)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?iju0ijkkd2.0ij>