From 82184b37afe9aa829bcf9516b4606d090b7ed181 Mon Sep 17 00:00:00 2001 From: Jo Simoens Date: Tue, 17 May 2005 22:50:30 +0000 Subject: [PATCH] I removed an entire paragraph that was repeated. The rest were minor typos or some superfluous words. --- docs/manual/tapetesting.tex | 27 +++++++++------------------ 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/docs/manual/tapetesting.tex b/docs/manual/tapetesting.tex index f57035b2..847c1a11 100644 --- a/docs/manual/tapetesting.tex +++ b/docs/manual/tapetesting.tex @@ -52,9 +52,9 @@ one. It isn't necessary to run the autochanger part of the test at this time, but do not go past this point until the basic test succeeds. -\item Run the btape {\bf fill} command, preferrably with two volumes. This +\item Run the btape {\bf fill} command, preferably with two volumes. This can take a long time. If you have an autochanger and it is configured, Bacula - will automatically use it. If you do not have it configured, you can manual + will automatically use it. If you do not have it configured, you can manually issue the appopriate {\bf mtx} command, or press the autochanger buttons to change the tape when requested to do so. \item FreeBSD users, run the {\bf tapetest} program, and make sure your @@ -163,7 +163,7 @@ directory. If your configuration file is elsewhere, please use the {\bf -c} option to specify where. The physical device name or the Device resource name must be specified on the -command line, and that this same device name must be present in the Storage +command line, and this same device name must be present in the Storage daemon's configuration file read by {\bf btape} \footnotesize @@ -517,7 +517,7 @@ Set -- Linux Only} If you have a modern SCSI tape drive and you are having problems with the {\bf test} command as noted above, it may be that some program has set one or more -of the your SCSI driver's options to non-default values. For example, if your +of your SCSI driver's options to non-default values. For example, if your driver is set to work in SysV manner, Bacula will not work correctly because it expects BSD behavior. To reset your tape drive to the default values, you can try the following, but {\bf ONLY} if you have a SCSI tape drive on a {\bf @@ -548,7 +548,7 @@ mt -f /dev/nst0 defblksize 0 \end{verbatim} \normalsize -If you would like to know what stoptions you have set before making any of the +If you would like to know what options you have set before making any of the changes noted above, you can now view them on Linux systems, thanks to a tip provided by Willem Riede. Do the following: @@ -606,15 +606,6 @@ mt -f /dev/nst0 defcompression 1 and of course, if you use a zero instead of the one at the end, you will turn it off. -You may also want to ensure that no prior program has set the default block -size, as happened to one user, by explicitly turning it off with: - -\footnotesize -\begin{verbatim} -mt -f /dev/nst0 defblksize 0 -\end{verbatim} -\normalsize - If you have built the {\bf mtx} program in the {\bf depkgs} package, you can use tapeinfo to get quite a bit of information about your tape drive even if it is not an autochanger. This program is called using the SCSI control @@ -643,7 +634,7 @@ BlockSize: 0 \normalsize where the {\bf DataCompEnabled: yes} means that tape hardware compression is -turned on. You can see it turn on and off (yes|no) by using the {\bf mt} +turned on. You can turn it on and off (yes|no) by using the {\bf mt} commands given above. Also, this output will tell you if the {\bf BlockSize} is non-zero and hence set for a particular block size. Bacula is not likely to work in such a situation because it will normally attempt to write blocks of @@ -885,7 +876,7 @@ tapes to ensure that the data has been written in a way that Bacula can recover it. Note, there is also a single tape option as noted below, which you should use rather than the two tape test. See below for more details. -This can be an extremely time consuming process (here is is about 6 hours) to +This can be an extremely time consuming process (here it is about 6 hours) to fill a full tape. Note, that btape writes random data to the tape when it is filling it. This has two consequences: 1. it takes a bit longer to generate the data, especially on slow CPUs. 2. the total amount of data is @@ -940,14 +931,14 @@ Bacula is configured to write fixed block sizes, it will pad the last block of the Job to the correct size. Bacula expects variable tape block size drives to behave as follows: Each write to the drive results in a single record being written to the tape. Each read returns a single record. If you request less -byte than are in the record, only those number of bytes will be returned, but +bytes than are in the record, only those number of bytes will be returned, but the entire logical record will have been read (the next read will retrieve the next record). Thus data from a single write is always returned in a single read, and sequentially written records are returned by sequential reads. Bacula expects fixed block size tape drives to behave as follows: If a write length is greater than the physical block size of the drive, the write will be -written as two blocks each of the fixed physical size. This a single write may +written as two blocks each of the fixed physical size. This single write may become multiple physical records on the tape. (This is not a good situation). According to the documentation, one may never write an amount of data that is not the exact multiple of the blocksize (it is not specified if an error -- 2.39.5