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