NAME
amtapetype - generate a tapetype definition by testing the device
directly
SYNOPSIS
amtapetype [-h] [-c] [-f] [-p] [-b blocksize] [-t typename] [-l label]
[{-o configoption}...] [config] [device]
DESCRIPTION
amtapetype generates a tapetype entry for Amanda by testing the device
directly.
OPTIONS
Note
The options for amtapetype have changed in version 2.6.1
-h
Display the help message.
-c
Run only the hardware compression detection heuristic test and
stop. This takes a few minutes only.
-f
Run amtapetype even if the loaded volume is already labeled.
-p
Run only the device property discovery.
-b blocksize
block size to use with the device (default: 32k)
-t typename
Name to give to the new tapetype definition.
-l label
Label to write on the tape (default is randomly generated).
-o configoption
See the "CONFIGURATION OVERRIDE" section in amanda(8).
If a configuration is specified, it is loaded and used to configure the
device. Note that global configuration parameters are not applied to
the device, so if you need to apply properties to a device to run
amtapetype, you should supply those properties in a named device
section.
EXAMPLE
Generate a tapetype definition for your tape device:
% amtapetype -f /dev/nst0
NOTES
If the device cannot reliably report its comprssion status (and as of
this writing, no devices can do so), hardware compression is detected
by measuring the writing speed difference of the tape drive when
writing an amount of compressable and uncompresseable data. If your
tape drive has very large buffers or is very fast, the program could
fail to detect hardware compression status reliably.
Volume capacity is determined by writing one large file until an error,
interpereted as end-of-tape, is encountered. In the next phase, about
100 files are written to fill the tape. This second phase will write
less data, because each filemark consumes some tape. With a little
arithmetic, amtapetype calculates the size of these filemarks.
All sorts of things might happen to cause the amount of data written to
vary enough to generate a strange file mark size guess. A little more
"shoe shining" because of the additional file marks (and flushes), dirt
left on the heads from the first pass of a brand new tape, the
temperature/humidity changed during the multi-hour run, a different
amount of data was written after the last file mark before EOT was
reported, etc.
Note that the file mark size might really be zero for whatever device
this is, and it was just the measured capacity variation that caused
amtapetype to think those extra file marks in pass 2 actually took up
space.
SEE ALSO
amanda(8), amanda.conf(5)
The Amanda Wiki: : http://wiki.zmanda.com/
AUTHORS
Dustin J. Mitchell <dustin@zmanda.com>
Zmanda, Inc. (http://www.zmanda.com)
Jean-Louis Martineau <martineau@zmanda.com>
Zmanda, Inc. (http://www.zmanda.com)