This is a collection of questions that 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!).
ftapesupport the Iomega 2GB tape drive?
Sorry, no, it doesn't. Iomega uses a proprietary data format on their
'Ditto 2GB' tape cartridges. The maintainer of
ftape has been
unable to get the necessary information to include support from the
You can achieve quite respectable backup and restore speeds with
ftape: a Colorado DJ-20 and an Adaptec 1542CF controller, has
been measured at 4.25Mbyte/min sustained data transfer rate (no
compression) across a 70Mbyte tar archive, while comparing the archive
on the tape with data on an IDE disk. The speed of
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).
There are three ways you can do this (in order of personal preference).
While we're at it, here are the meanings of the various trace levels.
If you are using the modules mechanism to load the
driver, you can specify the tracing level as an option to the insmod
/sbin/insmod ftape.o tracing=<tracing-level>
ftape driver has a hack in it that allows the
mt to be used to set the tracing level.
zftape does not
have this hack.
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.
tracing.c contains a line
int tracing = 3;.
Change the 3 to whatever is appropriate and recompile.
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.
These are really
tar questions: Please read the
man page and
info page. If you have not got it either, try `
--help 2>&1 | less'.
If your version of
tar is v1.11.1 or earlier, consider
upgrading to v1.11.8 - 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.
ftapeDMA 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
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
insmodsays the kernel version is wrong
insmod program can check the kernel version against the
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 `
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.
If you enable CONFIG_MODVERSIONS in the kernel, make sure you have
`-DMODVERSIONS -include /usr/include/linux/modversions.h' uncommented
in the MODULE_OPT line in the
ftape Makefile. Conversely, if
you do not have CONFIG_MODVERSIONS enabled, make sure you have it
insmodsays that kernel 1.2.0 and 1.2.0 differ
Did you remember to apply the
ksyms.c patch to the kernel? If
not, read the
README.linux-1.2 file in the source distribution.
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'
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
sunsite.unc.edu). In any case they can be fetched from the
official GNU home site:
[184.108.40.206]:/pub/gnu. The latest versions (as of September 12
cpio: 2.4.2 (cpio-2.4.2.tar.gz) dd: 3.13 (fileutils-3.13.tar.gz) mt: 2.4.2 (cpio-2.4.2.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
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.
When using compression, and in all general, it can be a benefit to
tar, that it should block the output into chunks.
ftape cuts things into 29Kbyte blocks, saying `
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.h files, for an explanation of the code and a reference to a
textbook on Reed-Solomon codes.
ftapedetects more bad sectors than DOS on QIC-3020 tapes
If you look at the difference, you will notice that
always detects 2784 sectors more than DOS.
The number that ftape reports is correct (of course
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 behavior 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.
The compile-time options NO_TRACE and NO_TRACE_AT_ALL in ftape control the amount of system logging. Add whichever is appropriate to the FTAPE_OPT line in the Makefile and recompile.
There been a few reports of `shoeshining'. This is when the tape just seems to run back and forth endlessly. This has been seen on a Jumbo 250 (email@example.com) and on an Iomega 250 Ditto Insider (firstname.lastname@example.org). In the latter case it has been narrowed own to using an ELF Linux and running off a SCSI hard disk (connected to an Adaptec 1542cf). Please contact me if you have an update to this problem.
ftapegives me the error`"modversions.h: no such file or directory'
modversions.h file is created when the kernel is compiled
with the configuration item
CONFIG_MODVERSIONS turned on. With
this option enabled, the file will be created during the
One more handy tip is that a
make mrproper will remove
/usr/include/linux/modversions.h. You will need to reconfig
the kernel and do a
make dep to get the file back.
(EOM is "End Of recorded Media", the position right after all data already recorded to the tape)
One cannot use tape "files" like files on an ordinary file system.
In principle, a tape doesn't allow anything but appending new data at EOM. However, if one positiones just in the middle of the already recorded data AND starts writing, then the driver first deletes all following files (thus moving the EOM to the actual position) and then starts writing.
Thus, the new EOM after finishing the write process, is then after the newly recorded data.
One of the consequences of the above is, of course, that writing to the tape in the middle of the already recorded area, is destructive in the sense, that it not only overwrites the "file" the tape is positioned at, but also deletes all following files.
You should only see this is you are trying to
ftape.o module. Try running
swapout first. It is provided
with the standalone
ftape source. It doesn't appear in the
ftape source that's provided with the kernel.
Here's an example of how you can set your rc.local file to use it.
# Install the Floppy Tape Driver if [ -f /boot/modules/`uname -r`/misc/ftape.o ]; then echo Installing ftape for Linux `uname -r` swapout insmod /boot/modules/`uname -r`/misc/ftape.o fi
Please note that you won't have this type of problem if you compile
ftape driver into the kernel.
Yes. The driver merely updates an internal counter when those commands are issues. The tape should move to the proper location on the next read or write access to the tape drive.