AMTAPETYPE(8)                                                    AMTAPETYPE(8)


       amtapetype - generate a tapetype definition.


       amtapetype [-h] [-c] [-o] [-b blocksize] [-e estsize] [-f tapedev]
                  [-t typename]


       amtapetype generates a tapetype entry for AMANDA.


       -h     Display an help message.

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

       -o     Overwrite the tape, even if it’s an AMANDA tape.

       -b  blocksize
              record block size (default: 32k)

       -e  estsize
              estimated tape size (default: 1g == 1024m)

       -f  tapedev
              tape  device  name  (default:  $TAPE)  The device to perform the

       -t  typename
              tapetype name (default: unknown-tapetype)


       Generate a tapetype definition for your tape device:

       % amtapetype -f /dev/nst0


       Hardware compression is detected by measuring the writing speed differ-
       ence  of  the tape drive when writing an amount of compressable and un-
       compresseable data. It does not rely on the status  bits  of  the  tape
       drive  or  the OS parameters. If your tape drive has very large buffers
       or is very fast, the program could fail to detect hardware  compression
       status reliably.

       During  the  first pass, it writes files that are estimated to be 1% of
       the expected tape capacity. It gets the expected capacity from  the  -e
       command  line  flag,  or defaults to 1 GByte. In a perfect world (which
       means there is zero chance of this  happening  with  tapes  :-),  there
       would be 100 files and 100 file marks.

       During  the  second  pass,  the  file size is cut in half. In that same
       fairyland world, this means 200 files and 200 file marks.

       In both passes the total amount of data written is summed  as  well  as
       the  number of file marks written. At the end of the second pass, quot-
       ing from the code:

       * Compute the size of a filemark as the difference in data written  be-
       tween  pass  1  and  pass 2 divided by the difference in number of file
       marks written between pass 1 and pass 2. ... *

       So if we wrote 1.0 GBytes on the first pass and 100 file marks, and 0.9
       GBytes  on  the  second  pass with 200 file marks, those additional 100
       file marks in the second pass took 0.1 GBytes and therefor a file  mark
       is 0.001 GBytes (1 MByte).

       Note  that if the estimated capacity is wrong, the only thing that hap-
       pens is a lot more (or less, but unlikely) files, and thus, file marks,
       get  written.  But  the  math  still works out the same. The -e flag is
       there to keep the number of file marks down because they  can  be  slow
       (since  they  force  the drive to flush all its buffers to physical me-

       All sorts of things might happen to cause the amount of data written to
       vary  enough  to  generate  a  big  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 re-
       ported, 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

       It  also  explains  why  amtapetype used to sometimes report a negative
       file mark size if the math happened to end up that way. When that  hap-
       pens now we just report it as zero.




Man(1) output converted with man2html