Last updated: 22nd November, 1996
Minor update: 11th December, 1997
This document is no longer actively maintained since compatibility is so much better now. Much of the information in this document is now included in the FTape-HOWTO
This document is not supposed to be a replacement for the information in the FTape-HOWTO; it is simply additional information I have gathered by monitoring the Linux newsgroups over the last few months.
I have attempted to gather information on people's real-life experiences using floppy tape drives. You should read this information in conjunction with the FTape-HOWTO.
DISCLAIMER: Please note that I do not have experience with any of these (except the Exabyte-EXB1500); I am simply reporting what I have seen in the newsgroups.
In principle, the ftape software should work with any QIC-117 drive using the QIC-40, QIC-80 or QIC-3010 standards. There is also some support for QIC-3020 drives, but most let you fall back to QIC-3010 mode. In practice, some tape drives have problems!
Note that IDE (QIC-3080) tape drives (e.g. Conner TapeStor 4000IDE) are supported by kernels from 1.3.46 on.
The latest versions of ftape do work with Linux/SMP (multiple processor support). You must remember to set -D__SMP__ somewhere in your Makefile. (Thanks to Kai Harrekilde-Petersen (khp@dolphinics.no) for updating me on this one.)
Warning: There is a report that ftape is broken under 2.0.16 from someone who was using it successfully under 2.0.14 (greg@gregp.clark.net). I haven't verified this.
Another similar report (jybarb01@homer.louisville.edu) suggests that ftape works with 2.0.15 but not with 2.0.17 and yet another report (hendriks@hops.cs.jhu.edu) says that ftape is broken in 2.0.16. However, a follow-up to that (dfly@infinet.com) suggests that the problem is fixed in 2.0.17 although there may still be problems like non-rewinding tapes not working properly.
Tom Wilson (twilson@uwyo.edu) has got ftape to work fine with 2.0.18, so it appears that this release fixes all the earlier problems.
Preston Crow (crow@coos.dartmouth.edu) reports that problems have come back again with 2.0.20!
ftape was originally written by Bas Larhoven, was then maintained by Kai Harrekilde-Petersen (khp@dolphinics.no), Kevin Johnson (kjj@primenet.com) and is now maintained by Claus-Justus Heine (claus@momo.math.rwth-aachen.de).
zftape is an alternative tape driver which supports compression. The first release of zftape was V2.03b as it was based on ftape 2.03b. Newer releases start from 1.02
As far as I can tell, development of zftape has now ceased. The additional functionality of zftape (i.e. compression) has been integrated into ftape as of ftape V3.0.
From kernel version 1.3.43 there is no longer ftape support in the kernel itself. The old kernel support simply allocated some DMA buffers and from kernel version 1.1.72, it became possible for modules to allocate their own DMA memory.
From kernel version 1.3.70 you need to use ftape 2.07 as the kernel has changed its use of interrupts.
From kernel version 1.3.74 there is direct support for ftape in the kernel. It is configured and compiled just like any other driver in the Linux kernel (either as a module or as part of the main kernel).
zftape has a compile-time option (DYN_ALLOC set in the Makefile) which causes DMA buffer allocation to be performed by zftape. It will therefore run on the newer kernels with no problems.
From ftape 2.05, the default is to support the newer kernels (where the ftape software has to allocate the DMA buffers). Therefore to use it with earler kernels (pre 1.3.43), you need to apply the supplied ksyms patch. See the directions below.
The latest official versions I know of are ftape 3.04d and zftape 1.06a. Both are available from Sunsite (in the kernel/tapes directory). UK mirror.
ftape-2.10 will now be out very soon which will support QIC-3020 at 2Mbps
Note that from Linux kernel version 1.3.74, ftape is included as a driver in the kernel itself, so you should only ever need to pick up patches and not the whole driver source once you upgrade to the latest kernels.
Because the support for ftape has been changing during the 1.3.x kernel series, the versions of ftape have been following these changes. Therefore, the latest versions of ftape do not work out of the box with 1.2.x kernels.
To get around this, you need to apply the ksyms.patch in the /patches/linux-1.2 directory of the ftape (or zftape) distribution and replace the original io.h file in the kernel source with the new one supplied in the distribution. This will take care of the exportation of the symbols that you're missing now and prevent ftape from allocating DMA buffers which is done by these earlier kernels.
Now, recompile your kernel and make sure you turn on CONFIG_MODVERSIONS as you're going through the make config part of the task. Boot the new kernel. Now, go into the Makefile for ftape (or zftape) and remove the "#" in the line with -DMODVERSIONS. Type make to recompile ftape and install the new ftape module (insmod ftape).
This description was modified from a posting by Mitchell Hamm (hamm@mail.one.net).
Different tape drives use different types of tape. The following is a brief summary of the capacities of some of the most common tape formats uncompressed and with 50% compression. The capacity of tape drives is often quoted using this compressed figure.
QIC-3010 340M/680M QIC-3020 680M/1300M TR1 400M/800M (QIC-80 with 8mm tape) TR2 800M/1600M (Equivalent to QIC-3010) TR3 1600M/3200M (Equivalent to QIC-3020)
In general, the higher capacity tapes (certainly QIC-3020) require a faster supply of data. Ordinary 512Kbps floppy disk controllers (FDCs) won't support the larger tape capacities.
The Iomega Ditto 1700 and the Exabyte EXB-1500 both require 2Mbps FDCs for QIC-3020 support; 2Mbps support is currently evolving in ftape. You must, therefore, use QIC-3010 tapes with these drives. Other drives may support higher capcities using a 1Mbps FDC (i.e. one which supports 2.88M floppy disks).
FTape-2.06 actually supports QIC-3020 (aka TR-3), but only in 1Mbps mode. The 2Mbps code is there, but isn't fully tested, so is switched off by default.
The only officially supported fast tape controllers which are supported are the Colorado FC-10 and FC-20 (ftape 2.03b onwards) and the Mountain MACH-2 (ftape 2.05 onwards). The IOmega Tape Accelerator II is compatible with the MACH-2.
To use these controllers you must uncomment the appropriate line from the Makefile:
FDC_OPT = -DPROBE_FC10 -DFDC_BASE=0x180 -DFDC_IRQ=9 -DFDC_DMA=3
There have been reports that the Iomega Ditto-Dash controller also works, but that it is not initialised properly. You can get around this by booting MS-DOS and using backup s/w before booting Linux. This correctly initialises the controller.
Ftape 2.05 correctly initialises the Ditto-Dash controller without first having to boot DOS (andrewk@ccwf.cc.utexas.edu).
Clearly, the DMA address you specify in the FDC_OPT must match what your controller has set and must not conflict with anything else. DMA=3 is often recommended.
A number of tape drives fail to report the tape length correctly when they are initialised. Code in the source file ftape-io.c requests the tape length from the drive and uses it to calculate the capacity of the tape and timeouts for rewinding.
According to Kai, this is now only used for calculating timeouts so shouldn't affect the tape capacity. I haven't actually tried not using the patch on the later versions of ftape, so I don't know if it's still necessary, but it can't do any harm...
If you find that you are not getting the capacity you expect from your tapes, you need to hack ftape-io.c. Find the routine ftape_report_configuration() and in that routine look for the switch statement: switch (status & QIC_TAPE_LEN_MASK). From the kernel log you should be able to see what tape length is being returned; simply correct the setting of *tape_len.
For example, the Iomega Ditto 800 Insider will always return QIC_TAPE_400FT and set *tape_len to 400; change this to 750 for 750ft tapes. The Exabyte EXB-1500 will return QIC_TAPE_FLEX and set *tape_len to 0; change this to 400.
A number of people have reported problems with tape positioning (i.e. adding archives to a tape by using mt fsf and the like) not working. This is probably a problem with them not having done mt erase to write markers to the tape first, although I do not have conformation on some of the drives that this is the case.
alias char-major-27 zftapeto conf.modules
Note that if you do make (z)ftape a dynamic module, you must only use the rewinding devices. If you don't you are risking your data on the tape, since ftape will postpone the writing of the header segment till 'later'; it won't get written if kerneld decides to rmmod (z)ftape! Thanks to Kai Harrekilde-Petersen (khp@dolphinics.no) for pointing this one out!.
zftape 1.05 is safe to use as a dynamic module if compiled with -DKERNELD_PROTECT. This prevents kerneld from unloading the module after non-rewinding devices are used. README.zftape implies that the module will stay in place until a rewinding device is used. Thanks to Scott Sellers (sds@cts.com) for clarifying this.
zftape is expensive to load, so you may wish to increase the time unused modules are kept alive. (millner@millner.bevc.blacksburg.va.us). Of course, you need modules-1.3.57 as well.
Steve Baumgartner (slbaumgartner@tasc.com) explained that ftape tries to allocate DMA buffers and can't get them because these buffers must be contiguous blocks of physical (not virtual) memory within the address range allowed by the DMA controller hardware. Other processes allocate physical memory in such a way that the necessary contiguous blocks can't be found for ftape. Three possible cures are:
Problems reported with the drive continually stopping and starting with zftape (75104.1756@compuserve.com). This appears to be a problem with the tape going too fast for the computer; the DMA buffers flushing before getting filled again. Newer versions of zftape don't do this any more if a suitably fast backup program or large DMA buffer size is used (millner@millner.bevc.blacksburg.va.us).
High speed Iomega controller works (muecker@csd.net).
"Timer expired" error reported (using TR-1 tapes with ftape 2.05-2.07) (les@amc.uva.nl).
Supposedly works fine with ftape 2.06 using a fast controller to support QIC-3020. Reported that the floopy disk can no longer read low-density floppies. May have to fiddle with IRQ/ports/dma channels (and therefore recompile ftape) (chris@yakkocs.wmich.edu).
{0x08882, 80, wake_up_colorado, "Iomega 3200"},
Works with tapes including TR-3.
Suggested that setting the IRQ to 7 helps (beej@inet-images.com)
1Mbps FDC will work (kjh@pollux.usc.edu) reportedly at 9.9Mbps (donar@cs.vu.nl).
One report of problems with the tape getting wound off the end of the
spool! Setup was Ditto/Dash controller (1Mbps mode), TR3 tapes, but
this could well be a hardware problem (rjm@swift.eng.ox.ac.uk).
Problem reported with ftape 2.07 and Kernel 1.12.13. With all sorts of combinations of accelerator, etc., the drive may (on some systems) only be accessed once (erwin@box.nl). Also, after the first access, the next use of the tape says it is write protected (erwin@box.nl, M.J.Ammerlaan@dutiwy.twi.tudelft.nl).
Both problems are caused by a bug on line 986 of ftape-io.c (bkelly@dropship.demon.co.uk). The original is:
int format_param = (qic_std << 4) + ((wide) ? 3 : 1);
It should actually be:
int format_param = (qic_std << 2) + ((wide) ? 3 : 1);
Another problem has been reported with writing archives (with dd) to the tape. It may start fine, but when the driver catches up with dd, it stops the tape and rewinds it to the beginning. Then it starts winding on through the tape ad infinitum. Appears to occur when the driver asks the tape to pause which should cause the tape to move back by 3 segments, but instead it moves back to the BOT. Brian Kelly (bkelly@dropship.demon.co.uk) is trying to fix this (27/3/96)
Other reports that the bug-fix (above) does not fully fix the write problem. (S.J.Cowley@damtp.cam.ac.uk)