amtapetype − generate a tapetype definition by testing the
device directly

amtapetype [−h] [−c] [−f] [−p] [−b blocksize] [−t typename]
[−l label] [−o configoption...] [config] [device]

     amtapetype generates a tapetype entry for Amanda by
testing the device directly.


          The options for amtapetype have changed in version

     Display the help message.

     Run only the hardware compression detection heuristic
     test and stop. This takes a few minutes only.

     Run amtapetype even if the loaded volume is already

     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

     −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.


     Generate a tapetype definition for your tape device:

     % amtapetype −f /dev/nst0

     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.

     amanda(8), amanda.conf(5)

     The Amanda Wiki: :

     Dustin J. Mitchell <>
     Zmanda, Inc. (

     Jean−Louis Martineau <>
     Zmanda, Inc. (