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