ftape-HOWTO
  Kevin Johnson, <kjj@pobox.com>
  v2.0, 15 March 1997

  This HOWTO discusses essential do's and dont's for the ftape driver
  under Linux.  The ftape driver interfaces to QIC-40, QIC-80, QIC-3010
  and QIC-3020 compatible drives.  The QIC-3010 and QIC-3020 standards
  are also known as `Travan' (TR-2 and TR-3).  These drives connects via
  the floppy disk controller (FDC).  It does not cover SCSI or QIC-02
  tape drives.  DAT tape drives usually (always?) connect to a SCSI con�
  troller.  This is but one of the Linux HOWTO documents.  You can get
  an index of the HOWTOs from the Linux HOWTO index
  <http://sunsite.unc.edu/mdw/HOWTO>, while the real HOWTO's can be
  fetched (using ftp) from sunsite.unc.edu:pub/Linux/doc/HOWTO (this is
  the ``official'' place) or via the World Wide Web from the Linux Docu�
  mentation Project home page <http://sunsite.unc.edu/mdw/linux.html>.

  1.  Legalese

  Linux ftape-HOWTO may be reproduced and distributed in whole or in
  part, subject to the following conditions:

       Copyright (c) 1993-1996 by Kai Harrekilde-Petersen
       Email: khp@dolphinics.no

       Copyright (c) 1996-1997 by Kevin Johnson
       Email: kjj@pobox.com

  Linux ftape-HOWTO is a free document; you may reproduce and/or modify
  it under the terms of version 2 (or, at your option, any later
  version) of the GNU General Public License as published by the Free
  Software Foundation.

  This howto is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  General Public License for more details.

  The author encourages wide distribution of this document for personal
  or commercial use, provided that the above copyright notice remains
  intact and the provisions of the GNU General Public License are
  adhered to.  The summary is that you may copy and distribute this
  document free of charge, or for a profit.  No explicit permission is
  required from the author for reproduction of this document in any
  medium, physical or electronic.

  Note that derivative works and translations of this document must be
  placed under the GNU General Public License, and the original
  copyright notice must remain intact.  If you have contributed new
  material to this document, you must make the source code (e.g., SGML
  source) available for your revisions.  Please make revisions and
  updates available directly to the author: Contact kjj@pobox.com via
  Internet e-mail.  This will allow the author to merge updates and
  provide consistent revisions to the Linux community.

  The author encourages distributors of Linux software in any medium to
  use the howto as an installation and user guide.  Given the copyright
  above, you are free to print and distribute copies of this document
  with your software.  If doing so, you may wish to include a short
  ``installation supplement'' for your release, or modify the relevant
  sections of this book to reflect your product.

  The author would like to know of any plans to publish and distribute
  this howto commercially.  In this way, we can ensure that you are kept
  up-to-date with new revisions.  And, should a new version be right
  around the corner, you might wish to delay your publication of the
  howto until it is available.

  If you are distributing this howto commercially, donations, royalties,
  and/or printed copies are greatly appreciated by the author.
  Contributing in this way shows your support for free software and the
  Linux Documentation Project.

  If you have questions or comments, please contact the author at
  kjj@pobox.com.

  2.  Revision History

     version 2.0 (March 15, 1997)

     �  Updated to ftape v2.11 and v3.xx

     �  Lots of updates.

     version 1.9 (September 20, 1996)

     �  New maintainers of ftape and the HOWTO.

     �  A few minor formatting and spelling fixes.

     �  Updated for Linux v2.0.

     �  Started to integrate some of Andrew Martin's ftape info.

     version 1.8 (May 22, 1996)

     �  Copyright policy changed to GNU GPL v2

     �  The maintainer's email address has changed.

     �  Updated to ftape-2.08

     �  ftape is now a part of the kernel distribution.

     version 1.7.1 (February 13, 1996)

     �  Updated to ftape-2.06b

     version 1.7 (January 28, 1996)

     �  Updated to ftape-2.06 and modules-1.3.57

     version 1.6.2 (January 23, 1996)

     �  Connor TST3200R drive added

     �  Updated 2Mbps fdc information.

     version 1.6.1 (January 16, 1996)

     �  minor corrections

     version 1.6 (January 10, 1996)

     �  New maintainer of ftape

     �  updated to v2.05

     �  added new drives

  3.  The preliminaries

  The maintainer of the source for ftape is Claus Heine
  <claus@momo.math.rwth-aachen.de>.  He has a web page at
  http://samuel.math.rwth-aachen.de/~LBFM/claus/ftape/ftape-page.html.

  If you have a problem or questions about ftape, try posting to the
  linux.dev.tape newsgroups.  This is a Usenet group that mirrors the
  traffic on the mailing list linux-tape@vger.rutger.edu (see
  ``Following the ftape development'' below).  It is recommended that
  the newsgroup be used in preference to the mailing list, since the
  vger machine is overburdened with the load of the Linux mailing lists.

  I use ftape (it is my sole means of backing up on my linux box :-).  I
  hesitate to make recommendations on what hardware to buy.  I use an
  Iomega Ditto Tape Insider 3200 and it seems to work OK for me, but I
  won't even try to tell you not to buy something else.  See the section
  ``Supported drives'' and ``Unsupported drives'' for a list of
  supported and unsupported drives.

  You should try to post a summary of your problems and its solution(s),
  after you've got it working, even if you only got it partially
  working. Please also send me (<kjj@pobox.com>) a copy of your solution
  or post it to the linux.dev.tape newsgroup so that I can add it to the
  HOWTO.

  I generally read my mail several times a week, I try to respond to
  everyone, but I cannot guarantee that I will respond immediately.  I
  usually read the newsgroups (linux.dev.tape and the kernel list).

  If you receive this as part of a printed distribution or on a CD-ROM,
  please check out the Linux Documentation home page
  <http://sunsite.unc.edu/mdw/linux.html> or ftp to
  <ftp://sunsite.unc.edu:/pub/Linux/doc/HOWTO> to see if there exists a
  more recent version.  This could potentially save you a lot of
  trouble.

  If you email me, please include the string ftape in the subject line.
  This will help ensure the mail doesn't inadvertently get buried.

  3.1.  What is ftape

  ftape is a driver program that controls various low-cost tape drives
  that connect to the floppy controller.

  ftape is not a backup program as such; it is a device driver, which
  allows you to use the tape drive (just like the SoundBlaster 16 driver
  let you use your sound card) through the device files
  /dev/[n]rft[0-3].

  ftape was originally written by Bas Laarhoven <bas@vimec.nl>, with ``a
  little help from his friends'' to sort out the ECC (Error Correcting
  Code) stuff. ftape is copyrighted by Bas under the GNU General Public
  License, which basically says: ``go ahead and share this with the
  world, just don't disallow other people from copying it further''.

  ftape is quite stable, and has been that for some time now.  It is
  reliable enough for critical backups (but it's always a good idea to
  check your backups, so you won't get a nasty surprise some day).

  ftape supports drives that conform to the QIC-117 and one of the
  QIC-80, QIC-40, QIC-3010, and QIC-3020 standards.

  ftape supports neither QIC-02, IDE (ATAPI), nor SCSI tape drives.
  SCSI drives are accessed as /dev/[n]st[0-7] and are supported by the
  kernel through the SCSI drivers.  If you look for help on SCSI tape
  drives, you should read the SCSI-howto.  ATAPI tape drives are
  supported by the kernel since 1.3.46.  See section ``Supported
  drives'' and ``Unsupported drives'' for a list of supported and
  unsupported drives.

  4.  Getting and installing ftape

  4.1.  Getting ftape

  The v2.0.X versions of the kernel have version 2.08 of ftape already.
  I recommend, however, that you grab the latest version of the full
  source code package for ftape. It is a newer version, includes files
  that are not included in the kernel distribution, and includes much
  better documentation about how to install ftape.

  Version 2.11a or newer of ftape is available from
  http://samuel.math.rwth-aachen.de/~LBFM/claus/ftape/ftape-page.html.
  At the time of writing this version of the HOWTO document, v3.xx is
  available.  I recommend sticking with v2.xx unless you are ready,
  willing, and able to use a development release with bugs.

  4.2.  Installing the driver

  The following sections provide some useful information to get you
  going with the installation of v2.11a.

  Once you've downloaded the source code (probably ftape-2.11a.tar.gz),
  untar it.  You can do this by determining what directory you want the
  source code to be located in.  I recommend /usr/src/ or ~/src.  When
  the tar file is extracted, it will dump everything into a ftape-2.11a
  subdirectory, so that you'll end up, in the example I've given, with
  something like /usr/src/ftape-2.11a or ~/src/ftape-2.11a.  It is
  possible to drop the entire ftape distribution into the
  /usr/src/linux/drivers/char/ftape directory, but untar the file into a
  location like I've suggested first, read through the documentation,
  then decide how you want to proceed.

  Read the README file.  The README is required reading.  It's the top
  of the tree, so to speak.  If there are specific files that the README
  tells you to read then read them.  It will make the process much less
  complicated.
  Do NOT proceed with compiling the package until you have read the
  appropriate README files and the Install-guide.

  The README mentions that the linux-tape mailing list.  I recommend
  subscribing to the linux.dev.tape newsgroup instead.  The machine
  serving the mailing list is overburdened.

  There are two ways that ftape support can be added to the kernel.

  �  Compile it directly into the kernel.

  �  Compile it as a kernel module.

  Of these two methods, the first has fewer potential problems.  The
  second has the benefit of only consuming memory while the driver is
  loaded.  The original author of ftape (Bas Laarhoven) has pointed out
  that ftape was not originally designed to be used with modules.

  I compile ftape directly into the kernel on my computer.  In general,
  fewer difficulties or complications are reported when it is done this
  way.  A good rule of thumb is to compile it into the kernel unless you
  both have a good reason not to and are willing to accept any of the
  complications that can arise from doing otherwise.  If you do compile
  it into the kernel, please keep in mind that you cannot use zftape
  instead of ftape because the two use the same major device number.

  If you are compiling the driver directly into the kernel, you can
  generally ignore the instructions regarding modules.

  If you have a v1.2 kernel, you should use the modules-1.3.57 package,
  not the modules-1.2.8 package (Bj�rn Ekwall, maintainer of the modules
  package, encourages this).

  If you are using v1.3.x of the kernel, you should consider moving to
  v2.0.x.  v1.3.x was the development release prior to the production
  release v2.0.x.

  4.3.  Following the development of the ftape driver

  If you want to follow the development of the ftape driver, you should
  read the Usenet newsgroup linux.dev.tape.  This is really gatewayed
  from the mailing list linux-tape@vger.rutgers.edu, but since vger is
  brought to it's knees due to the load of the various Linux mailing
  lists, I recommend everyone to read the newsgroup instead.

  If you are unable to read news, you can subscribe to the TAPE mailing
  list by sending a mail saying `subscribe linux-tape' (in the body) to
  majordomo@vger.rutgers.edu.  When you subscribe, you will be sent a
  greeting mail, which will tell you how to submit real mails and how to
  get off the list again.

  Please note that I do not, repeat DO NOT, have any special powers with
  regard to this mailing list.  If you're stuck on the list, don't
  bother to tell me that.  I can only shrug and send you my sympathy
  (but that won't get you off the list).

  4.4.  Mixing ftape and floppies

  Since both the floppy driver and ftape needs the FDC (and IRQ6), they
  cannot run concurrently.  Thus, if you have mounted a floppy and then
  try to access the tape drive, ftape will complain that it cannot grab
  IRQ6 and then die.  This is especially a problem when designing a
  emergency disk for use with ftape.  This solution is to either load
  the boot/root disk into a ramdisk and then unmount the floppy, or have
  two floppy drive controllers.

  5.  The Care and Feeding of Tape and Tape Drives

  5.1.  Formatting

  Before a tape can be used, it must be formatted.  The formatting
  process lays out sector information onto the tape.  Other tape
  interfaces don't typically require formatting.  The reason floppy
  tapes do is that they need to look like a floppy (kinda gross, but
  what the hey - it works :-).

  5.1.1.  Can I format my tapes under Linux?

  Not yet, but it's being worked on.

  Until formatting becomes available under Linux, you'll have to use
  MessyDOS (arghhh!)  instead or buy preformatted tapes.  However, some
  of the preformatted tapes are not checked for bad sectors!.  If the
  ftape driver encounters a tape with no bad blocks, it will issue a
  warning.  If ftape barfs at your preformatted tapes, try out your DOS
  software.  If both the DOS software and ftape barfs on your tapes, a
  reformat will very probably cure the problem.

  Note that to be able to use your newly formatted tapes under ftape,
  you must erase the tape first:

               # mt -f /dev/nftape erase

  5.1.2.  Which formatting programs can I use under DOS?

  The following are known to work:

  �  Colorado Memory System's software (tape.exe)

  �  Conner Backup Basics v1.1 and all Windows versions

  �  Norton Backup

  �  QICstream version 2

  �  Tallgrass FileSecure v1.52

  �  Escom Powerstream 3.0 (qs3.exe -- QICstream v3?)

  These programs are known to be more or less buggy:

  �  Conner Backup Basics 1.0

  �  Colorado Windows tape program

  �  CP Backup (wastes tape space, but is OK apart from that)

  As a general rule, most software under DOS should work.  The Conner
  Backup Basics v1.0 has a parameter off by one (someone could not read
  the QIC-80 specs right!), which is corrected in version 1.1.  However,
  ftape detects this, and will work around it.  Dennis T. Flaherty
  (<dennisf@denix.elk.miles.com>) report that Conner C250MQ owners can
  obtain the new v1.1, by calling Conner at 1-800-4Conner (in the US)
  and ask for an upgrade (for a nominal fee for the floppy).  The
  Windows versions should work fine.  Some versions of Colorado's tape
  program for windows, has an off-by-one error in the number of
  segments. ftape also detect and work around that bug.

  Central Point Backup can be used, but it wastes precious tape space
  when it encounters a bad spot on the tape.

  NOTE: If you are running a formatting software under DOS, which is not
  mentioned here, please mail the relevant info to me (<kjj@pobox.com>),
  so I can update the list.

  5.2.  Retensioning

  QIC tapes are particularly sensitive to tape stretch.  The reason is
  that floppy tapes are pre-formatted with sector information, whereas
  other tape types have their sync information written as the data is
  written to the tape.  If the floppy tape stretches and the sync fields
  get out of sync the result will be read errors.  The problem is worse
  with longer tapes.

  It is a good idea to retension new tapes a few times before using them
  and before formatting them.  You should also try retensioning the tape
  if you are start getting read errors.  It might also be a good idea
  retension the tape before a backup.

  5.3.  Drive Cleaning

  The coating on the tape is an oxide compound.  As the tape is dragged
  across the tape head it has a tendency to leave tiny amounts of
  residue on the head.  You should periodically use a tape cleaner -
  following the specs for the drive in question.  Tape cleaners should
  be available from any distributer of tapes.

  One more additional note about tape cleaning.  You might want to clean
  the drive after the first use of a brand new tape.  A brand new tape
  will typically leave quite a bit of residue the first time it's used.

  Thanks to Neal Friedman for the explanation and suggestion that this
  information be included in the HOWTO.
  6.  Hardware support

  6.1.  Supported tape drives

  All drives that are both QIC-117 compatible and one of the QIC-40, 80,
  3010, and 3020 standards should work.  QIC-WIDE and Travan drives are
  also supported (TR-1 is just QIC-80 with 8mm tapes, while TR-2 and
  TR-3 is a.k.a QIC-3010 and 3020 respectively).

  Currently, the list of drives that are known to work with ftape is:

     Alloy Retriever 250

     Archive 5580i, XL9250i

     Colorado DJ-10, DJ-20 (aka: Jumbo 120, Jumbo 250)

     Colorado 1400
        <kosowsky@bellini.harvard.edu> reported a problem doing a 1G
        backup using taper.

     HP Colorado T1000
        Works with 3M Travan 400M (TR-1) tapes with 120M tapes.  Also
        reported that mt dies, but with backups using tar it works ok.
        With cpio, ftape is recommended rather than zftape.
        (<millner@millner.bevc.blacksburg.va.us>)

        Problems have been 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 are getting flushed beforee getting
        filled again.  Newer versions of zftape don't do this any more
        is a suitably fast backup program or large DMA buffers are used
        (<millner@millner.bevc.blacksburg.va.us>).

     Conner C250MQ(T)
        The 250Q is reported to generate write error and frequent
        repositioning. (Frank Stuess at Nacamar Data Communications)

     Conner TSM420R, TSM850R
        The 400 and 800 models only work with TR-1 tapes.

     Conner TST3200R
        Works with TR-3 tapes at 1Mbps (ie. 1600M capacity only).  Wirks
        with QIC-WIDE 400M tapes (Sony 5122's?)  (<chris@cs.wmich.edu>).
        Works with TR3, QIC-3010, and QIC-3020 tapes.  Comes with a 2MB
        FDC which the Promise 2300+ 1Mbps controller works
        (<kjh@pollux.usc.edu>).  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 the CTC-2MB
        controller (<merkel@def.gmpt.gmeds.com).

        Supposedly works fine with ftape 2.06 using a fast controller to
        support QIC-3020.  Reported that the floppy disk can no longer
        read low-density floppies.  May have to fiddle with
        IRQ/ports/dms channels (<chris@yakkocs.wmich.edu>).

     Conner TST800R
        The TST800R works with TR-1, Sony QW5122F (210M) and DC2120
        tapes.  Reported to work with ftape 2.02e (not 2.03b).  It works
        with ftape 2.05 (<khp@pip.dknet.dk>).  Requires the length
        patch.  Reported that you may need to nodify the Makefile to
        ensure ftape talks to the PRIMARY floppy drive controller
        (>jzc@primenet.com>).  Also, a "Timer expired" error reported
        (using TR-1 tapes with ftape 2.05-2.07) (<les@amc.uva.nl>).

     Conner CTT3200

        The CTT3200 is supposedly identical to the Iomega Ditto 3200.
        It works with the supplised 2Mbps controller (but at 1Mbps), but
        reported not to work under DOS on some machines.
        (<jmorris@dtx.net>)

     Conner 1.7G Tapestor (TSM1700R)

        Works with QIC-WIDE tapes (<pschmidt@slip.net>).  Partially
        works with QIS-3200.  Using the HSC-2 controller, the DMA
        channel needs to be changed (incremented by 1, channel2?, 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) (<ttait@tiac.net>).  It
        may not work at 2Mbps (QIC-3020) with the HSC controller.  The
        tape died with a messages like "dumb tape stop" and has since
        been unreliable (<ttait@tiac.net>).

     Escom or Archive (Hornet) 31250Q

     Exabyte EXB-1500
        Work with QIC-3010 tapes.  Requires the length patch.

     Exabyte TR-3

     Irwin 80SX, Insight 80Mb

     Iomega 250

     Iomega Ditto Tape Insider 420, 1700

     Iomega Ditto Tape Insider 3200
        This is the unit, that I use.  The default jumper settings don't
        work.  Leave the irq and ioport address at the default (6 and
        0x370, respectfully), but change the DMA from 3 to 2.

        May require the having {0x08882, 80, wake_up_colorado, "Iomega
        3200"}, added to vendors.h on older versions of ftape.

        Problems 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>).
        There has been one report of a problem where the tape got wound
        off the end of the spool.

        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.  It
        appears to occur when the driver asks the tape to pause which
        should cause the tape to move back by 3 segments, but instead is
        moves back to the beginning of the tape.  A bug fix submitted is
        reported to not solve the solve the problem.

     Iomega Ditto 800 Insider
        Work with Travan TR1, TR2, or DC2120 tapes
        (<klein@informatik.uni-rostock.de>).  Requires the length patch.

     Mountain FS8000

     Reveal TB1400

        Reported not to work with kernel 1.3.79 and ftape (no version
        given) or with kernel 1.2.13 and zftape 1.04
        (<colin@colina.demon.co.uk>).

     Summit SE 150, SE 250

     Tallgrass FS300
        If you have a Tallgrass FS300 and an AHA1542B, you need to
        increase the bus-on / bus-off time of the 1542B.  Antti Virjo
        (<klanvi@uta.fi>), says that changing CMD_BUSON_TIME to 4 and
        CMD_BUSOFF_CMD to 12 in linux/drivers/scsi/aha1542.c will do the
        trick.

     Teac 800

     Memorex tape drive backup system

     Wangtek 3040F, 3080F

  You can always check out the newest list of drives that are recognized
  by ftape, by looking in the file vendors.h in the ftape distribution.

  Although I do not want to endorse one drive type over another, it has
  been reported that the Colorado DJ-20 drive is rather noisy, when
  compared to, say, a Conner C250MQ drive ('tis said that the Colorado
  is 5-10 times as noisy as the Conner drive. Since I have neither, I
  can't tell for sure).

  NOTE: If you have a drive that works fine, but it is not listed here,
  or if you have corrections to the above information, please send a
  mail to the HOWTO maintainer (<kjj@pobox.com>).

  6.2.  Supported special controllers

  These dedicated high-speed tape controllers are supported by ftape:

  �  Colorado FC-10, FC-20

  �  Mountain MACH-2

  �  Iomega Tape Accelerator II

  �  2Mbps controllers (using the i82078-1 fdc)

  Support for the FC-10 controller has been merged into the ftape driver
  in version 1.12. See the RELEASE-NOTES and the Makefile files in the
  ftape distribution.  Since of version 2.03 of ftape, the FC-20
  controller will work (but do check the Release notes!).

  The support for the MACH-2 controller was added in ftape-1.14d.

  To use the Iomega Tape Accelerator II, use -DMACH2, and set the right
  settings for I/O base, IRQ and DMA.  This works (by the empirical
  testing of Scott Bailey <sbailey@xcc.mc.xerox.com>), with at least
  ftape-2.02.

  6.2.1.  Iomega Ditto Dash and other 2Mbps controllers

  The Iomega Ditto Dash, and all other known 2Mbps controllers, use the
  Intel 82078-1 chip, which can run at 2Mbps.  Support for the 82078-1
  is currently under development.  It is hoped that the support will be
  completed during January or February.

  Current status is that it will work at 1Mbps, with 2Mbps support
  coming soon (I hope!).

  6.3.  Unsupported tape drives

  �  All drives that connect to the parallel port (eg: Colorado Trakker)

  �  Irwin AX250L / Accutrak 250. (not a QIC-80 drive)

  �  IBM Internal Tape Backup Unit (identical to the Irwin AX250L drive)

  �  COREtape light

  Generally, ALL drives that connect to the parallel port are NOT
  supported.  This is because these drives uses (different) proprietary
  interfaces, that are very much different from the QIC-117 standard.

  The Irwin AX250L (and the IBM Internal Tape Backup Unit) does not work
  the ftape.  This is because they only support QIC-117, but not the
  QIC-80 standard (they use Irwin's proprietary ``servoe (Rhomat)''
  format).  I know nothing about the Rhomat format, nor where to get any
  info on it.  Sorry.

  The COREtape light does not accept the initialisation commands, we're
  feeding it. This pretty much leaves the drive unusable.

  The Iomega 2GB Ditto drive does not work with ftape.  That particular
  tape uses a proprietary format that the Claus has not been able to get
  information on.

  6.4.  Using an external tape drive with ftape

  If you have a floppy controller which has a female DB37 connector on
  the bracket (and some means of delivering power to the drive), you can
  use it with ftape.  OK, that sentence was not very obvious. Let's try
  it this way: Some FDC's (the very ancient one's), have a DB37
  connector on the bracket, for connecting to external floppy drives.

  If you make a suitable cable from the DB37 connector (on the FDC) to
  your external tape drive, you can get ftape to control your tape
  drive.

  This is because that from a program's view there is no difference
  between the internal and the external connectors. So, from ftape's
  point of view, they are identical.

  �  Pins 20-37: GROUND

  �  1: +12 Volt (POWER)

  �  2: +12 Volt return (GROUND)

  �  3: +5 Volt return (GROUND)

  �  4: +5 Volt (POWER)

  �  5: 2

  �  6: 8

  �  7: 10

  �  8: 12

  �  9: 14

  �  10: 16

  �  11: 18

  �  12: 20

  �  13: 22

  �  14: 24

  �  15: 26

  �  16: 28

  �  17: 30

  �  18: 32

  �  19: 34

  The power connector is of the "mini" type, sitting on 3.5" floppy
  drives.  The idea appears to be that you plug one of the power
  connectors from the PSU to this connector on the board.  If you want
  to use just a single cable, you might want to get a 50 wire cable, and
  use multiple wires for the power lines (and ground, for that matter).

  I have received no confirmation from anyone that this works.  Let me
  know your results if you try it.

  6.5.  PCI motherboards and ftape

  Unfortunately, some PCI motherboards cause problems when running
  ftape.  Some people have experienced that ftape would not run in a PCI
  based box, but ran flawlessly in a normal ISA based 386DX machine.  If
  you have such a problem, please read the README.PCI file in the ftape
  distribution.

  7.  Backing up and restoring data

  This section describes some simple uses of tar and mt.

  7.1.  Writing an archive to a tape

  You can use `tar', `dd', `cpio', and `afio'. You will need to use `mt'
  to get the full potential of your tapes and the ftape driver.  For a
  start I'd recommend using `tar', as it can archive lots of directories
  and let you pick out separate files from an archive.  cpio creates
  smaller archives and is more generally more flexible than tar, but is
  missing some features like volume labels.  `afio' creates backups
  where each file is compressed individually and then concatenated.
  This will allow you to access the files ``after'' the point of the
  error.  If you use gzipped tar files, all data after the point of the
  error is lost! (to me, this is a pretty good reason for NOT using
  compression on backups).  The choice of which is most appropriate
  depends on the situation and the features and malfeatures of each of
  the packages.  I recommend taking a look at each package at reviewing
  the options that each provides.  It's possible that this HOWTO may
  provide more detail on this subject at some point in the future.

  To make a backup of your kernel source tree using tar, do this
  (assuming you have the sources in /usr/src/linux):

               # cd /usr/src
               # tar cf /dev/ftape linux

  This will not compress the files, but gives you a smoother tape run.
  If you want the compression (and you've got tar 1.11.2), you just
  include the -z flag(*), eg: `tar czf /dev/ftape linux'

  For further instructions on how to use tar, dd and mt look at the man
  pages and the texinfo files that comes with the respective
  distributions.

  (*) tar assumes that the first argument is options, so the `-' is not
  necessary, i.e. these two commands are the same: `tar xzf /dev/ftape'
  and `tar -xzf /dev/ftape'

  7.2.  Restoring an archive

  OK, let us restore the backup of the kernel source you made in section
  ``Writing an archive to a tape'' above.  To do this you simply say

               tar xf /dev/ftape

  If you used compression, you will have to say

               tar xzf /dev/ftape

  When you use compression, gzip will complain about trailing garbage
  after the very end of the archive (and this will lead to a `broken
  pipe' message).  This can be safely ignored.

  For the other utilities, please read the man page.

  7.3.  Testing the archive

  tar has an option (-d) for detecting differences between two archives.
  To test your backup of the kernel source say

               tar df /dev/ftape

  If you do not have the man page for tar, you are not lost (yet); tar
  has a built-in option list: try `tar --help 2>&1 | less'

  7.4.  Putting more than one backup on a tape

  To put more than one backup on a tape you must have the mt utility.
  You will probably have it already, if you got one of the mainline
  distributions (eg. Slackware or Debian).

  Programs like tar and cpio generate a single Tape ARchive and know
  nothing about multiple files or positioning of a tape, it just reads
  or writes from/to a device. mt knows everything about moving the tape
  back and forth, but nothing about reading the data off the tape.  As
  you might have guessed, combining tar or cpio with mt does the trick.
  By using the nrft[0-3] (nftape) device, you can use `mt' to position
  the tape the correct place (`mt -f /dev/nftape fsf 2' means step over
  two ``file marks'', i.e.  tar files) and then use tar or cpio to read
  or write the relevant data.

  The most common use of the non-rewinding device is to append another
  backup to an existing tape.  Here are the specific steps with a little
  explanation thrown in for good measure.

  �  Insert a tape into the drive.  On some devices this may cause the
     tape to be rewound.

  �  Issue an End-of-Tape command to the NON-rewinding device.

               mt -f /dev/n???? eof

  The tape should now be positioned at the End-of-Tape (EOT), which is
  actually between to End-of-File (EOF) marks.  The tape won't move
  unless a program opens the device, closes the rewinding device,
  removes the device driver from kernel memory (rmmod) or ejects the
  tape.  Using `mt eof' may be faster on QIC tapes.

  �  The next tape operation will start at the End-of-Tape (EOF) mark.
     If you perform a write, it will append a new `file'.  If you
     perform a read it will fail with EOF.  The EOT mark on mast tape
     formats is actually two consecutive EOF marks.  When appending to a
     tape the second EOF mark is overwritten with new data, leaving a
     normal EOF.  If the second EOF is present, it is interpreted as a
     logical EOF.  Writing the EOF marks is handled by either the device
     driver or the hardware when a close() is performed.

  �  Here's where you write the actual data to the tape.

  �  Here's the important part. Now rewind the tape.  Both ftape and
     zftape cache some information that belongs in the header segments
     on the tape and update those header segments only when the tape is
     rewound.  This caching is necessary because rewinding the tape and
     updating the header segments takes a conspicious amount of time.
     The drawback of this caching is that you will lose information if
     you have written to the tape and not rewound the device.

  7.5.  Appending files to an archive

  ``Is there a way to extend an archive -- put a file on the tape, then
  later, add more to the tape?''

  No. The tar documentation will tell you to use `tar -Ar', but it does
  not work.  This is a limitation of the current ftape driver.

  7.6.  Mount/unmounting tapes

  Since a tape does not have a ``filesystem'' on it, you do not mount /
  unmount the tape.  To backup, you just insert the tape and run your
  `tar' command (or whatever you use to access the tape with).

  8.  Creating an emergency boot floppy for ftape

  This section was written by Claus T�ndering <ct@login.dknet.dk>.

  Once you are the happy owner of a tape drive and several tapes full of
  backups, you will probably ask yourself this question: ``If everything
  goes wrong, and I completely lose my hard disk, how do I restore my
  files from tape?''

  What you need is an emergency floppy disk that contains enough files
  to enable you to boot Linux and restore your hard disk from tape.

  The first thing you should do is to read ``The Linux Bootdisk HOWTO''
  written by Graham Chapman <grahamc@zeta.org.au>.  That document tells
  you almost everything you need to know about making an emergency
  floppy boot kit.  The paragraphs below contain a few extra pieces of
  information that will make your life a bit easier when you follow
  Graham Chapman's procedures:

  �  You don't really need /etc/init, /etc/inittab, /etc/getty, and
     /etc/rc.d/* on your floppy disk.  If Linux doesn't find /etc/init,
     it will start /bin/sh on your console, which is fine for restoring
     your system.  Deleting these files gives you extra space on your
     floppy, which you will probably need.

  �  Find a small version of /bin/sh.  They are frequently available on
     the boot floppies that come with a Linux distribution.  This again
     will give you extra space.  I'd suggest ash, which is extremely
     small (approx 62Kbytes), and yet very bash compatible.

  �  The /etc/fstab you include on your floppy disk should look
     something like this:

               /dev/fd0        /               minix   defaults
               none            /proc           proc    defaults
               /dev/hda        /mnt            ext2    defaults

  Once you have booted from your floppy, give the command:

               mount -av

  �  Make sure your floppy drive is not mounted when you access the
     streamer tape!  Otherwise you may get the following error message:

          Unable to grab IRQ6 for ftape driver

  This means that you MUST load the floppy into a RAMDISK.

  This has the unfortunate consequence that the programs needed to
  restore the files from the tape can not be located on a separate
  floppy disk.  You have two options here:

     1. You place tar (or cpio or afio or whatever other backup program
        you use) on your root floppy disk.  (This is where you'll need
        all the extra space created in the steps above.)

     2. Before you start restoring from tape, copy tar (or cpio or afio
        or whatever) to your hard disk and load it from there.

  �  Apart from your backup program, you will probably need mt on your
     root floppy as well.

  �  Make sure your ftape device (typically /dev/nrft0) is present on
     your boot floppy.

  �  Finally: TRY IT OUT! Of course, I don't recommend that you destroy
     your hard disk contents to see if you are able to restore
     everything.  What I do recommend, however, is that you try booting
     from your emergency disks and make sure that you can at least make
     a file listing of the contents of your backup tape.

  9.  Frequently Asked Questions

  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!).

  9.1.  Does ftape support the Iomega 2GB tape drive?

  Sorry, no, it doesn't.  Iomega uses a proprietary data format on their
  unable to get the necessary information to include support from the
  vendor.

  9.2.  How fast is ftape?

  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 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).
  9.3.  How do I change the trace-level?

  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.

  �  0 Bugs

  �  1 + Errors

  �  2 + Warnings

  �  3 + Information

  �  4 + More information

  �  5 + Program flow

  �  6 + FDC/DMA info

  �  7 + Data flow

  �  8 + Everything else

  9.3.1.  Using insmod to change trace-level

  If you are using the modules mechanism to load the ftape driver, you
  can specify the tracing level as an option to the insmod command.

               /sbin/insmod ftape.o tracing=<tracing-level>

  9.3.2.  Using mt to change trace-level

  The ftape driver has a hack in it that allows the fsr option in 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.

  9.3.3.  Recompiling to change trace-level

  The file tracing.c contains a line int tracing = 3;.  Change the 3 to
  whatever is appropriate and recompile.

  9.4.  Can I exchange tapes with someone using DOS?

  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.

  9.5.  How do I `....' with 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 | 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.

  9.6.  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.

  9.7.  insmod says the kernel version is wrong

  The 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.

  9.8.  What is this versioned symbols stuff anyway?

  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.

  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 commented
  out.

  9.9.  insmod says 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.

  9.10.  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'

  9.11.  binaries/sources/manpages?  Where can I find the tar/mt/cpio/dd

  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 (as of September 12 1996) are:

               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 v1.0.4 / libc v4.5.19 / gcc
  v2.5.8.

  9.12.  Where can I obtain the QIC standards?

  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.

  9.13.  What block-size should I use with 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 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.

  9.14.  ftape detects more bad sectors than DOS on QIC-3020 tapes

  If 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 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.

  9.15.  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.  Add whichever is appropriate to the
  FTAPE_OPT line in the Makefile and recompile.

  9.16.  `Shoeshining'

  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 (74407.3051@compuserve.com) and on an Iomega 250 Ditto Insider
  (tom@opus.cais.com). 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.

  9.17.  `"modversions.h: no such file or directory' Trying to compile
  ftape gives me the error

  The 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 make dep step.

  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.

  9.18.  in the middle?  How does `mt eom' work when you've started
  overwriting a tape

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

  9.19.  Help! I'm getting 'dmaalloc() failed' in my syslog file.

  You should only see this is you are trying to insmod the 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
  the ftape driver into the kernel.

  9.20.  Is it ok that I'm not hearing the tape move when I do a fsf or
  a bsf with mt?

  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.

  10.  Debugging the ftape driver

  10.1.  The kernel/ftape crashes on me when I do `...' - is that a bug?

  No, that is a feature ;-)

  Seriously, reliable software do not crash.  Especially kernels do not
  or rather should not crash.  If the kernel crashes upon you when you
  are running ftape, and you can show that it is ftape that is messing
  things up, regard it as a Bug That Should Be Fixed.  Mail the details
  to the maintainer (<kjj@pobox.com>) and to the tape list.

  10.2.  OK, it's a bug ...ehhh... feature - How do I submit a report?

  First, make sure you can reproduce the problem.  Spurious errors are a
  pain in the ass, since they are just about impossible to hunt down :-/
  This is a quick check list:

  �  Kernel version, and patches applied

  �  ftape version

  �  tape drive model / manufacturer

  �  Expansion bus type (EISA, ISA, PCI, or VL-bus)

  �  What you did to expose the problem

  �  What went wrong on your system.

  �  Do not delete the kernel and the ftape.o file. I might want you run
     try some patches out or run a different test on your system.

  Increase the tracing level to 7 (just below maximum tracing) and run
  the offending command again.  Get the tracing data from the kernel log
  or /proc/kmsg, depending on where you harvest your error messages.
  Try to look at what ftape spews out at you.  It may look in-
  comprehensible to you at first, but you can get valuable information
  from the logfile.  Most messages have a function name prepended, to
  make it easier to locate the problem.  Look through the source, don't
  just cry ``WOLF!'', without giving it a try.  If your version of the
  kernel (or ftape for that matter), is ``old'', when compared to the
  newest version of the kernel, try to get a newer (or even the newest)
  kernel and see if the problem goes away under the new kernel.  When
  you post your problem report, include the information about ftape
  version, kernel version, expansion bus type (ISA, VL-bus, PCI or
  EISA), bus speed, floppy controller, and tape drive.  State exactly
  what you did, and what happened on your system.  Some people have
  experienced that ftape would not run in a PCI based box, but ran
  flawlessly in a normal ISA based 386DX machine (see section ``Getting
  PCI motherboards to work with <tt/ftape/'' on PCI machines above)

  Also, please think of the poor souls who actually pay the their
  Internet access (like me): avoid posting a (huge) log from the ftape
  run, without reason.  Instead, you could describe the problem, and
  offer to send the log to the interested parties.

  Send your bug report to <linux-tape@vger.rutgers.edu>. You might also
  want to mail the bug to <claus@momo.math.rwth-aachen.de>.

  11.  Contributions

  The following is a list of notable folks that have contributed to
  ftape and it's HOWTO document.  This is a recent addition added by
  someone coming in midstream.  My sincerest apologies if I've
  inadvertently left someone important off the list.

  Kai Harrekilde-Petersen <khp@dolphinics.no>: The previous maintainer
  of ftape and the HOWTO.

  Andrew Martin <martin@biochemistry.ucl.ac.uk>: Many additions to the
  HOWTO.

  Bas Laarhoven <bas@vimec.nl>: The original author of ftape.