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!).
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 errors Sadly 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 wrong The insmod
program checks the kernel version against the version
recorded in the ftape
driver. This is a string in
kernel-version.h
, (e.g.: #define KERNEL_VERSION "1.1.72";
)
which is extracted from the kernel you are running when you run `make
dep
'. If you got the error when you tried to insert the ftape
driver, remove the file `kernel-version.h
', type `make dep;
make
' again and the kernel-version.h
file should be updated.
Remember that you will have to do this every time you change to another kernel
version.
ftape
complains that ``This tape has no 'Linux raw format'
''You get this complaint, if you haven't erased your freshly formatted
tape. This is because ftape
wants a ``magic header'' on the tape, to
be able that it is allowed to interpret the header segment in it's own way
(eg: file marks). To remove the problem, say `mt -f /dev/nftape
erase
'
tar
/mt
/cpio
/dd
binaries/sources/man pages?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
26. march 94) are:
cpio: 2.3 (cpio-2.3.tar.gz)
dd: 3.9 (fileutils-3.9.tar.gz)
mt: 2.3 (cpio-2.3.tar.gz)
tar: 1.11.2 (tar-1.11.2.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
(The rmt
program does not compile
out of the box, but it is not needed as it is only used for accessing the tape
drive remotely). 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 and perhaps QIC-117. QIC-117 describes how
commands are sent to the tape drive (including timing etc), so you would
probably never need it. QIC-80 describes the tape layout, ECC code, standard
filesystem and all such ``higher-level'' stuff. You can get the QIC standards
from the following address:
Quarter Inch Cartridge Drive Standars, Inc.
311 East Carrillo Street
Santa Barbara, California 93101
Phone: (805) 963-3852
Fax: (805) 962-1541
tar
When 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 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, they an explanation of the code and a reference to a
textbook on Reed-Solomon codes.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter