git.gag.com Git - debian/amanda/blob - man/amtapetype.8.in

   1 .\"
   2 .de EX
   3 .if t .ft C
   4 .nf
   5 ..
   6 .de EE
   7 .fi
   8 .if t .ft
   9 ..
  10 .TH AMTAPETYPE 8
  11 .SH NAME
  12 amtapetype \- generate a tapetype definition.
  13 .SH SYNOPSIS
  14 .B amtapetype
  15 [-h]
  16 [-c]
  17 [-b blocksize]
  18 [-e estsize]
  19 [-f tapedev]
  20 [-t typename]
  21 .SH DESCRIPTION
  22 .B Amtapetype
  23 generate a tapetype entry for amanda.
  24 .SH OPTIONS
  25 .PP
  26 .TP 10
  27 .B \-h
  28 Display an help message.
  29 .TP
  30 .B \-c
  31 Run only the hardware compression detection heuristic test and stop.
  32 This takes a few minutes only.
  33 .TP
  34 .BI \-b "\| blocksize\^"
  35 record block size (default: 32k)
  36 .TP
  37 .BI \-e "\| estsize\^"
  38 estimated tape size (default: 1g == 1024m)
  39 .TP
  40 .BI \-f "\| tapedev\^"
  41 tape device name (default: $TAPE)
  42 The device to perform the test.
  43 .TP
  44 .BI \-t "\| typename\^"
  45 tapetype name (default: unknown-tapetype)
  46 .PD
  47 .SH EXAMPLE
  48 Generate a tapetype definition for your tape device:
  49 .LP
  50 .RS
  51 .nf
  52 % amtapetype -f @DEFAULT_TAPE_DEVICE@
  53 .SH NOTES
  54 Hardware compression is detected by measuring
  55 the writing speed difference of the tape drive
  56 when writing an amount of compressable and uncompresseable data.
  57 It does not rely on the status bits of the tape drive or the OS parameters.
  58 If your tape drive has very large buffers or is very fast, the program
  59 could fail to detect hardware compression status reliably.
  60
  61 During the first pass, it writes files that are estimated to be 1%
  62 of the expected tape capacity.  It gets the expected capacity from
  63 the -e command line flag, or defaults to 1 GByte.  In a perfect world
  64 (which means there is zero chance of this happening with tapes :-),
  65 there would be 100 files and 100 file marks.
  66
  67 During the second pass, the file size is cut in half.  In that same
  68 fairyland world, this means 200 files and 200 file marks.
  69
  70 In both passes the total amount of data written is summed as well as the
  71 number of file marks written.  At the end of the second pass, quoting
  72 from the code:
  73
  74    * Compute the size of a filemark as the difference in data written
  75    * between pass 1 and pass 2 divided by the difference in number of
  76    * file marks written between pass 1 and pass 2.  ...
  77
  78 So if we wrote 1.0 GBytes on the first pass and 100 file marks, and
  79 0.9 GBytes on the second pass with 200 file marks, those additional 100
  80 file marks in the second pass took 0.1 GBytes and therefor a file mark
  81 is 0.001 GBytes (1 MByte).
  82
  83 Note that if the estimated capacity is wrong, the only thing that happens
  84 is a lot more (or less, but unlikely) files, and thus, file marks,
  85 get written.  But the math still works out the same.  The -e flag is
  86 there to keep the number of file marks down because they can be slow
  87 (since they force the drive to flush all its buffers to physical media).
  88
  89 All sorts of things might happen to cause the amount of data
  90 written to vary enough to generate a big file mark size guess.  A little
  91 more "shoe shining" because of the additional file marks (and flushes),
  92 dirt left on the heads from the first pass of a brand new tape, the
  93 temperature/humidity changed during the multi-hour run, a different amount
  94 of data was written after the last file mark before EOT was reported, etc.
  95
  96 Note that the file mark size might really be zero for whatever device this
  97 is, and it was just the measured capacity variation that caused amtapetype
  98 to think those extra file marks in pass 2 actually took up space.
  99
 100 It also explains why amtapetype used to sometimes report a negative file
 101 mark size if the math happened to end up that way.  When that happens
 102 now we just report it as zero.
 103 .SH "SEE ALSO"
 104 amanda(8)