This is a collection of questions I get asked once in a while, which could fall into the category of FAQ's. If you feel that there is some question that ought to be added to the list, please feel free to mail me (but do include an answer, thanks!).
ftape?You can achieve quite respectable backup and restore speeds with
ftape: I have a Colorado DJ-20 and an Adaptec 1542CF controller, and
have measured a 4.25Mbyte/min sustained data transfer rate (no compression)
across a 70Mbyte tar archive, while comparing the archive on the tape with
data on my IDE disk. The speed of ftape is mostly dependent on the
data transfer rate of your FDC: The AHA1542CF has a ``post-1991 82077'' FDC,
and it will push 1Mbit/sec at the tape drive. If you have an FDC which can
only deliver 500Kbit/sec data rates, you will see half the transfer rate
(well, roughly).
You can do this two ways: either change the default trace-level (the var
`tracing' in file `ftape-rw.c') and recompile or say
mt -f /dev/ftape fsr <tracing-level>
The use of the fsr command in mt is a hack, and
will probably disappear or change with time.
No. The DOS software conforms to the QIC-80 specs about the layout of the DOS filesystem, and it should(?) be a small problem to write a program that can read/write the DOS format. In fact, I'd bet that creating a nice user interface would be a bigger problem.
tar?These are really tar questions: Please read the man page and
the info page. If you have not got it either, try `tar --help
2>&1 | more'.
If your version of tar is v1.11.1 or earlier, consider upgrading to
v1.11.2 - This version can call GNU zip directly (i.e.: it supports
the -z option) and has an elaborate help included. Also, it compiles
right out of the box on Linux.
ftape DMA transfers gives ECC errorsSadly to say there are some SVGA cards and ethernet cards that do not decode
their addresses correct. This typically happens when the ftape
buffers are in the range 0x1a0000 to 0x1c0000. Somehow, the
DMA write cycles get clobbered and every other byte written gets a bad value
(0xff). These problems are reported to happen with both SVGA and
ethernet cards. We know of at least one (bad?) ATI 16bit VGA card that caused
this.
The easiest solution is to put the card in an 8bit slot (it is often not
enough to reconfigure the card to 8bit transfers). Moving the ftape
buffer away from the VGA range is only a partial solution; All DMA buffers
used in Linux can have this problem! Let us make this one clear: This has
nothing to do with the ftape software.
insmod says the kernel version is wrongThe insmod program can check the kernel version against the version
that ftape was compiled for in two ways: It can directly compare the
kernel version number recorded in the ftape module against the version of the
running kernel, or, if both the kernel and ftape is compiled with
versioned symbols, compare the version of the used kernel symbols.
If you have upgraded your version of GCC to v2.7.0 or later, you must recompile the modules utilities with gcc v2.7.x.
Newer versions of insmod allows you to ``force'' insertion of a
module into the kernel, even though the version string is incorrect.
When you say `yes' to CONFIG_MODVERSIONS during `make config', all
the symbols exported by the kernel, i.e: the symbols that the loadable modules
can ``see'', are augmented to include a checksum across the types of the
call/return parameters. This allows insmod to detect whether the
definition of a variable or function in the kernel has changed since the time
when ftape was compiled.
This ensures a high degree of safety, such that you do not crash the kernel because you used an outdated module with your kernel.
insmod says that kernel 1.2.0 and 1.2.0 differDid you remember to aply the ksyms.c patch to the kernel? If not,
see
Quick guide to compiling the kernel
above.
ftape says ``This tape has no 'Linux raw format'''You get this complaint if you haven't erased your freshly formatted
tape. This is because ftape expect a ``magic header'' on the tape,
to be able that it is allowed to interpret the header segment in its own way
(eg: file marks). To remove the problem, say `mt -f /dev/nftape
erase'
tar/mt/cpio/dd binaries/sources/manpages?All of these tools have been developed by the GNU project, and the source (and
man page) can be fetched from just-about any ftp site in the world (including
ftp.funet.fi, tsx-11.mit.edu, and sunsite.unc.edu).
In any case they can be fetched from the official GNU home site:
prep.ai.mit.edu [18.71.0.38]:/pub/gnu. The latest versions (by
10. january 96) are:
cpio: 2.4.1 (cpio-2.4.1.tar.gz)
dd: 3.12 (fileutils-3.12.tar.gz)
mt: 2.4.1 (cpio-2.4.1.tar.gz)
tar: 1.11.8 (tar-1.11.8.tar.gz)
gzip: 1.2.4 (gzip-1.2.4.tar.gz)
They all compile out of the box on Linux v1.0.4 / libc
v4.5.19 / gcc v2.5.8. There is a patch for mt included
in the ftape distribution, which makes the mt status command
spew out usable information for ftape drives.
If you wish to help developing ftape, or add some utility (e.g. a
tape formatting program), you will need that appropriate QIC standards. The
standard(s) to get is: QIC-80, -117, -3010, and 3020. QIC-117 describes how
commands are sent to the tape drive (including timing etc), so you would
probably never need it. QIC-80/3010/3020 describes higher level part, such as
tape layout, ECC code, standard filesystem. You can get the QIC standards
from the following address:
Quarter Inch Cartridge Drive Standards, Inc.
311 East Carrillo Street
Santa Barbara, California 93101
Phone: (805) 963-3853
Fax: (805) 962-1541
Note: They are registered as `Freeman Associates, Inc' in the phone book.
tarWhen using compression, and in all general, it can be a benefit to specify to
tar, that it should block the output into chunks. Since
ftape cuts things into 29Kbyte blocks, saying `-b58' should
be optimum.
``Why 29Kbyte?'', I hear you cry. Well, the QIC-80 standard specifies that
all data should be protected by an Error Correcting Code (ECC) code. The code
specified in the QIC-80 standard is known as a Reed-Solomon (R-S) code. The
R-S code takes 29 data bytes and generates 3 parity bytes. To increase the
performance of the ECC code, the parity bytes are generated across 29 1Kbyte
sectors. Thus, ftape takes 29Kbytes of data, adds 3Kbytes of ECC
parity, and writes 32Kbytes to the tape at a time. For this reason, ftape
will always read and write 32K byte blocks to be able to detect (and correct)
data errors.
If you are curious, and wish to know more, look in the ecc.c and
ecc.h files, for an explanation of the code and a reference to a
textbook on Reed-Solomon codes.
ftape detects more bad sectors than DOS on QIC-3020 tapesIf you look at the difference, you will notice that ftape always
detects 2784 sectors more than DOS.
The number that ftape reports is correct (of course :-). Each
correctly formatted QIC-3020 tape has 2784 sectors at fixed positions that are
marked in the bad sector map. To quote from the specs:
``Tracks 5,7,9,11,13,15,17,19,21,23,25 and 27 within 4 segments of either EOT or BOT are prone to increased error rates due to hole imprints. Therefore, these regions shall be mapped as bad at format time and entered in the bad sector map by indicating that all sectors within the identified segments are bad.''
This gives 12 tracks * 2 * 4 segments * 29 sectors == 2784 sectors.
So ftape choose to report the real number of sectors that cannot be used on the tape, while DOS gives a more optimistic number giving a better indication of tape quality. (ftape's behaviour might change in the future to detect correct formatting and display the separate numbers. It has rather low priority though).
QIC-3010 are alike QIC-3020 tapes regarding this.