Linux Floppy Tapes

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 ( for updating me on this one.)

Latest Kernels

Warning: There is a report that ftape is broken under 2.0.16 from someone who was using it successfully under 2.0.14 ( I haven't verified this.

Another similar report ( suggests that ftape works with 2.0.15 but not with 2.0.17 and yet another report ( says that ftape is broken in 2.0.16. However, a follow-up to that ( 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 ( has got ftape to work fine with 2.0.18, so it appears that this release fixes all the earlier problems.

Preston Crow ( reports that problems have come back again with 2.0.20!

FTape and ZFTape

ftape was originally written by Bas Larhoven, was then maintained by Kai Harrekilde-Petersen (, Kevin Johnson ( and is now maintained by Claus-Justus Heine (

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.

New versions of ftape with older 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 (

Types of Tape

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:


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 (

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.

The Length Patch

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.

Tape Positioning

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.

Other useful Info

Syslogd works overtime when running ftape

The compile-time options NO_TRACE and NO_TRACE_AT_ALL in ftape control the amount of system logging, so you can cut it down. Add one to the FTAPE_OPT line and recompile.

Running ftape/zftape with kerneld

Kerneld is a dynamic module loader (i.e. modules get unloaded again as system load increases and the module isn't being used). Add:
alias char-major-27 zftape
to 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 ( 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 ( for clarifying this.

zftape is expensive to load, so you may wish to increase the time unused modules are kept alive. ( Of course, you need modules-1.3.57 as well.


There have been a couple of reports of "shoeshining". This is when the tape just seems to run back and forth endlessly. This has been seen on a Jumbo 250 ( and an Iomega 250 Ditto Insider ( In the latter case it has been narrowed down to using an ELF Linux and running off a SCSI hard disk (connected to an Adaptec 1542cf) and an exact bug description will soon be sent to the ftape authors (

Failure to load as a Module

Ian T Zimmerman reported a problem that after a few days of uptime, "modprobe ftape" fails, with a klogd message saying something like "dmalloc failed". i.e. the ftape module would not load until a reboot.

Steve Baumgartner ( 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:

  1. Make ftape a compiled-in driver instead of a module such that the buffers will be allocated once only during boot. (The problem being that upto 100K of physical memory will be permanently used by ftape).
  2. Kill off other processes until enough memory is free.
  3. Force other processes out to swap until enough memory is free. Since ftape 2.06 a program called 'swapout' comes with the full distribution (though not with the kernel distribution). It allocates and dirties lots of memory forcing allocation of physical memory, forcing other processes to swap out, then frees the memory. You can also do: dd if=/dev/zero of=/dev/null count=1 bs=8192k where the last number is the amount of RAM minus a bit...

Problem with Multiple Volumes

Jonathan Neal Deitch (musjnd@panther.Gsu.EDU) has reported a problem with ftape 2.08 (kernels 1.3.76 and 2.0.0) failing on multi volume backups which worked with 1.2.13/2.06. Watch this space...

Miscellaneous Problems

A problem has been reported with ftape 2.09 and 2.10 with kernel version 2.0.24 (2.09 worked fine with 2.0.0) (

Specific Tape Drives

Colorado Jumbo 120 (IDE Version)

Works with Linux kernel 1.2.13 (

Colorado Jumbo 250 (=DJ20)

(Model now replaced by the Jumbo 350.) Works.

Colorado Jumbo 350

Problem reported with mt fsf not working, but see above.

Colorado Jumbo 1400

Works. ( reported a problem doing a 1 gig backup using taper.

Colorado T1000

Works with 3M Travan 400M (TR-1) tapes and with 120M tapes. Also reported that mt dies, but that backups with tar work OK. ftape rather than zftape recommended with cpio (

Problems reported with the drive continually stopping and starting with zftape ( 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 (

High speed Iomega controller works (

Conner 250Q

Reported to generate write errors and frequent repositioning. (Frank Stuess at Nacamar Data Communications)

Conner CTT3200

Suppusedly identical to the Iomega Ditto 3200. Works with supplied 2Mbps controller (but at 1Mbps), but reported not to work under DOS on some machines!! (

Conner TSM420


Conner TSM850


Conner TST800R

Works with TR-1, Sony QW5122F (210M) and DC2120 tapes. Reported only to work with ftape 2.02e (not 2.03b). Works with ftape 2.05 ( Requires the length patch. Reported that you may need to modify the Makefile to ensure ftape talks to the PRIMARY floppy drive controller (

"Timer expired" error reported (using TR-1 tapes with ftape 2.05-2.07) (

Conner 1.7G Tapestor (TSM1700R)

Works with QIC-WIDE tapes ( Partially works with QIC-3020. Using the HSC-2 controller, the DMA channel needs to be changed (increment by 1, channel 2?, Modify the Makefile). You then need to modify the ftape Makefile to reflect this change. However, ftape seems to be a bit flaky with this (no version number supplied...) ( May not work at 2Mbps (QIC-3020) with the HSC controller. Tape died with a message like "dumb tape stop" and since been unreliable (

Conner Travan 400/800

Works only with TR-1 tapes.

Conner TST3200

Works with TR-3 tapes at 1Mbps (i.e. 1600M capacity only). Works with QIC-WIDE 400M tapes (Sony 5122's?) ( Works with TR3, QIC-3010 amd QIC-3020 tapes. Comes with a 2MB FDC which The Promise 2300+ 1Mbps controller works ( Works with ftape 2.05; NOTE: ftape 2.03, 2.04, and zftape 1.03 don't work Booting problems reported with ftape-2.06 and QIC-3020 with CTC-2MB controller (

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) (

Exabyte EXB-1500

Works with QIC-3010 tapes. Requres the length patch.

Exabyte TR-3

Reported to be problems with QIC-3020 ( However, the problems seem to be coming from the FDC not the tape drive itself.

Iomega Ditto 800 Insider

Works with Travan TR1, TR2 or DC2120 tapes ( Requres the length patch.

Iomega Ditto 1700

Works with QIC-3010 tapes.

Iomega Ditto 3200

You may need to add the following line to vendors.h:
{0x08882, 80, wake_up_colorado, "Iomega 3200"},
Works with tapes including TR-3. Suggested that setting the IRQ to 7 helps ( 1Mbps FDC will work ( reportedly at 9.9Mbps ( 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 (

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 ( Also, after the first access, the next use of the tape says it is write protected (,

Both problems are caused by a bug on line 986 of ftape-io.c ( 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 ( is trying to fix this (27/3/96)

Other reports that the bug-fix (above) does not fully fix the write problem. (

Reveal TB1400

Reported not to work with Kernel 1.3.79 and ftape V??? or with Kernel 1.2.13 and zftape 1.04 (

Teac 800

Works (Ed Skladany,

Wangtek 3080F


Other Tape drives

The following drives are listed as working in the FTape-HOWTO, but I have no further information from the Newsgroups:

Drives reported NOT to work

Conner CTM1360

( Doesn't work (ftape up to 2.05) as is QIC-3020 only. (

Exabyte Eagle96

This QIC-3020 drive currently doesn't work, but this is being worked on. Partially functional with versions of tape supporting the Exabyte TR-3 (Nancy Milligan ) Will be fully supported in ftape-2.10 (Bas Laarhoven )