<!doctype linuxdoc system>
<!-- Hey! Yo! Emacs! we're -*- SGML -*-  -->
<!-- This document was formatted using a fill-column of 72 in emacs -->

<article>

<title>Ftape-HOWTO
<author>Claus-Justus Heine, <htmlurl url="mailto:heine@math1.rwth-aaachen.de"
name="&lt;heine@math1.rwth-aachen.de&gt">
<date>v3.0, August 1998

<abstract>
This HOWTO discusses essential do's and dont's for the <tt/ftape/
floppy tape driver under Linux. It focusses on the newest version
which is <tt/ftape-4.02/ at the time of this writing. This HOWTO is to
be intended as first step help and source of information.

The <tt/ftape/ driver interfaces to QIC-40, QIC-80, QIC-3010 and
QIC-3020 compatible drives, and to the Iomega Ditto 2GB and Ditto Max
drives.  The QIC-3010 and QIC-3020 standards are also known as
`Travan' (TR-2 and TR-3).  These drives connect via the floppy disk
controller (<bf/FDC/) which may be either an internal FDC or inside of
certain parallel port floppy tape drives. Please refer to the section
<ref id="supp_drives" name="Supported drives"> for further
information.

<tt/ftape/ <bf>does not</bf> cover SCSI or QIC-02 tape drives.  DAT tape
drives usually (always?) connect to a SCSI controller.

This is but one of the Linux HOWTO documents.  You can get an index of
the HOWTOs from <htmlurl
url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX.html" name="the
Linux HOWTO index">, while the real HOWTO's can be fetched (using
<tt/ftp/) from <tt>sunsite.unc.edu:pub/Linux/doc/HOWTO</tt> (this is
the ``official'' place) or via the World Wide Web from <htmlurl
url="http://sunsite.unc.edu/LDP" name="the Linux Documentation Project
home page">.
</abstract>

<toc>

<sect>Legalese<p>

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

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

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

Copyright (c) 1998 by Claus-Justus Heine
Email: heine@math1.rwth-aachen.de
</verb>
</tscreen>

The 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
heine@math1.rwth-aachen.de 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

heine@math1.rwth-aachen.de

<sect>Revision History<p>

<descrip>
<tag>version 3.0 (August, 1998)</tag>
	<itemize>
        <item> Additions to list of supported hardware.
	<item> New section about differences between ftape versions.
	<item> Pointers to the Ftape-FAQ and the Ftape manual.
	<item> Updated to ftape-4.02.
	<item> Additions to the FAQ.
	<item> Update all URLs.
	</itemize>
<tag>version 2.0 (March 15, 1997)</tag>
	<itemize>
	<item> Updated to ftape v2.11 and v3.xx
	<item> Lots of updates.
	</itemize>
<tag>version 1.9 (September 20, 1996)</tag>
	<itemize>
	<item> New maintainers of ftape and the HOWTO.
	<item> A few minor formatting and spelling fixes.
	<item> Updated for Linux v2.0.
	<item> Started to integrate some of Andrew Martin's ftape info.
	</itemize>

<tag>version 1.8 (May 22, 1996)</tag>
	<itemize>
	<item> Copyright policy changed to GNU GPL v2
	<item> The maintainer's email address has changed.
	<item> Updated to ftape-2.08
	<item> <tt/ftape/ is now a part of the kernel distribution.
	</itemize>
<tag>version 1.7.1 (February 13, 1996)</tag>
	<itemize>
	<item> Updated to ftape-2.06b
	</itemize>
<tag>version 1.7 (January 28, 1996)</tag>
	<itemize>
	<item> Updated to ftape-2.06 and modules-1.3.57
	</itemize>
<tag>version 1.6.2 (January 23, 1996)</tag>
	<itemize>
	<item> Connor TST3200R drive added
	<item> Updated 2Mbps fdc information.
	</itemize>
<tag>version 1.6.1 (January 16, 1996)</tag>
	<itemize>
	<item> minor corrections
	</itemize>
<tag>version 1.6 (January 10, 1996)</tag>
	<itemize>
	<item> New maintainer of <tt/ftape/
	<item> updated to v2.05
	<item> added new drives
	</itemize>
</descrip>


<sect>The preliminaries<p>

<sect1>Other sources of information<p>

<descrip>
<tag/ftape version 3/

<tt/ftape-3.x/ came with a manual of its own, which is contained in
the <tt/ftape-3.04d/ package available from the usual places.  See
<ref id="getting" name="Getting Ftape">.

<tag/ftape version 4/

<tt/ftape-4.x/ also has a documentation package <tt/ftape-doc/ which
is available from the usual places. This Ftape-HOWTO, however, also
focusses on <tt/ftape-4.x/ and is meant as an entry point to the
available documentation. See <ref id="getting" name="Getting Ftape">.

<tag/ftape-tools/

The <tt/ftape-tools/ package (including useful utilities for
<tt/ftape/) comes with its own manual.  See <ref id="getting"
name="Getting Ftape">.

<tag/Ftape-FAQ/

The <tt/Ftape-FAQ/ is included wordly in this manual, but more recent
versions may be found at <htmlurl url="http://www.correct.nl/~ftape"
name="http://www.correct.nl/~ftape">.

</descrip>

<sect1>Contacts<p>

The maintainer of the source for <tt/ftape/ is Claus Heine <htmlurl
url="mailto:heine@math1.rwth-aachen.de"
name="&lt;heine@math1.rwth-aachen.de&gt">.  He has a web page at
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">.

If you have a problem or questions about ftape, try posting to the
<tt/Linux Tape/ mailing list <tt/linux-tape@vger.rutger.edu/ (see <ref
id="tape-channel" name="Following the ftape development"> below).  There
also used to be a newsgroup that mirrored the mailing list traffic but
it has vanished some time ago.

I use <tt/ftape/ (it is my sole means of backing up on my linux box :-).
I hesitate to make recommendations on what hardware to buy.  See the
section <ref id="supp_drives" name="Supported drives"> and <ref
id="unsupp_drives" name="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 a copy of your solution to the Linux Tape
mailing list at <htmlurl url="mailto:linux-tape@vger.rutgers.edu"
name="&lt;linux-tape@vger.rutgers.edu&gt"> so that it can be added to
the HOWTO and/or the FAQ.

If you receive this as part of a printed distribution or on a CD-ROM,
please check out <htmlurl url="http://sunsite.unc.edu/LDP/"
name="the Linux Documentation home page"> or ftp to
<htmlurl url="ftp://sunsite.unc.edu:/pub/Linux/doc/HOWTO"
name="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 <tt/ftape/ in the subject
line.  This will help ensure the mail doesn't inadvertently get
buried. But preferrably you should email to the Linux Tape mailing list
at <htmlurl url="mailto:linux-tape@vger.rutgers.edu"
name="&lt;linux-tape@vger.rutgers.edu&gt"> instead of contacting me
directly.


<sect1>What is <tt/ftape/<p>

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

<tt/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
<tt>/dev/[n]qft[0-3]</tt>.

<tt/ftape/ was originally written by Bas Laarhoven
<tt/&lt;bas@vimec.nl&gt/, with ``a little help from his friends'' to
sort out the ECC (Error Correcting Code) stuff. <tt/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''.

<tt/ftape/ has undergone several changes since then. While the
Linux-2.0.x kernel series still contains <tt/ftape-2.08/ the v2.1.x
and soon the v2.2.* kernel series come with <tt/ftape-3.x/ (hopefully
even with <tt/ftape-4.02/, but this wasn't clear at the time of this
writing) which differs in some points from the <tt/ftape-2.x/ driver.
Since version <tt/3.00/ the <tt/ftape/ driver has been maintained by
me (Claus-Justus Heine); it has been changed and improved in several
respects and support for new hardware has been added.

<tt/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).

<tt/ftape/ supports drives that conform to the QIC-117 and one of the
QIC-80, QIC-40, QIC-3010, and QIC-3020 standards as well as the Iomega
Ditto 2GB and Ditto Max drives which no longer strictly conform to the
QIC standards in all respects.

<tt/ftape/ can drive floppy tape drives that connect to the internal FDC 
as well as certain parallel port floppy tape drives.

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


<!-- ****** Getting and installing ftape ****** -->


<sect>Getting and installing <tt/ftape/<p>


<sect1>Getting <tt/ftape/<label id="getting"><p>

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

<!-- The v2.1.x and later versions of the kernel have the newer version -->
<!-- 4.00 already. So in this case you don't need to download the kernel -->
<!-- driver sources. -->

I recommend that you download the latest stable version of <tt/ftape/
which is 4.02 at the time of this writing and is available from

<htmlurl
url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/archives.html"
name="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/archives.html">

as well as from

<htmlurl
url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes/"
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes/">.

You probably should also grab the <tt/ftape-doc/ and the
<tt/ftape-tools/ package that are available from the same locations.

If you still want to use the <tt/ftape-2.08/ which is shipped with the
v2.0.x kernels, then you get a version of the driver which is really
out of date and doesn't support QIC-3020 tapes at 2Mbps correctly,
neither does it support the Ditto 2GB drives nor the Ditto Max drives
nor any kind of parallel port tape drive. The section
<ref id="supp_drives" name="Supported drives">
gives detailed information about which version of the <tt/ftape/ driver
supports which hardware.

<sect1>Differences between <tt/ftape-2.x/, <tt/ftape-3.x/ and <tt/ftape-4.x/ versions<p>

<tt/ftape-3.x/ and <tt/ftape-4.x/ use the file system interface that
was implemented for a branch release which was called
<tt/zftape/. Actually, the module that implements the <bf/VFS/
(<tt/Virtual File System/) interface of <tt/ftape-3.x/ and
<tt/ftape-4.x/ still is called <tt/zftape.o/ and its <tt/C/-sources
inside the kernel tree reside in
<tt>[/usr/src/linux/]drivers/char/ftape/zftape/</tt>.

<tt/ftape-2.x/ (i.e. the version still contained in the v2.0.x kernel)
uses another file system interface, that was implemented by
<tt/ftape's/ original author Bas Larhoven.

<descrip>
<tag/File Marks/
The conceptional difference between <tt/ftape-2.x/ and later versions
of <tt/ftape/ is the way <em/file marks/ are implemented.

<em/Floppy tape devices/ don't have real file marks.<footnote> <bf/File
marks/ are used to distinguish different backup sets if you write
multiple backup sets to a tape. SCSI and QIC-150 tapes have
<em>real</em> file marks, i.e. between two different backup sets there
is a region on the tape that is written special data to so that the
drive logic can detect that marker when the tape is wound with
(possibly) high speed over those file marks.</> Because the goal
of <tt/ftape's/ file system interface was from the beginning on to
provide an interface that could be used with standard Unix-like tape
utilities (i.e. <tt/mt/) the developers of <tt/ftape/ started to
emulate file marks by storing the positions on the tape where a file
mark should be located in certain fields of the header
segments.<footnote><bf>header segments</> refers to a region at the
beginning of the tape sized two times 29k to hold some important
information about the tape format and size and some status
information.</>

However, the <tt/QIC/ standards already designate a special region to
store such information in, the so called <bf/volume table
segment/. Since <tt/ftape-3.x/ this <em/volume table segment/ is used
instead of using unused data fields in the header segment. As a result
it is possible to use your tape cartridge with different operating
systems in the sense that your Win or DOS backup program will realize
that certain regions of the tape cartridge are already occupied with
data, and <tt/ftape-3.x/ and later will detect the regions used by
those DOS and Win programs. However, you can't extract a DOS backup
set under Linux or extract a volume written by <tt/ftape/ under DOS,
safe you write your own software to do that.

<tag/IOCTL interface/

There are certain differences in the <bf/IOCTL/<footnote>This <em/IO
control/ interface is used by e.g. <tt/mt/ to rewind the tape or skip
to the next file mark or do any other tape operation.
</footnote>
interface between <tt/ftape-2.x/ and <tt/ftape-3.x/ and later. A
detailed description can be found in the <tt/ftape-manual/ contained
in the <tt/ftape-doc/ package.  See <ref id="getting" name="Getting
Ftape">.

<tag/Formatting/

Formatting of cartridges is supported with <tt/ftape-3.x/ and later
<bf/only/. Please get the <tt/ftape-tools/ package that contains the
<tt/ftformat/ program that interfaces to the driver to format
cartridges.  See <ref id="getting" name="Getting Ftape">. The
<tt/ftape-tools/ package comes with (more or less) detailed
documentation, so the case of formatting cartridges is not dealt with
in this document.

<tag/Compression/

<tt/ftape-3.x/ supported user transparent on-the-fly compression in
software. This feature (or <em/bug/) has vanished in <tt/ftape-4.x/ as
it made further improvements concerning the realiability of backups
very very hard. This means, <tt/ftape-4.x/ comes without compression
support.

However <bf/de-compression/ of compressed archives produced with
<tt/ftape-3.x/ <bf/is/ supported in order not to brake existing backup
programs where a user-level filter would not suffice to preserve
compatibility. Think, e.g., of <tt/taper/ which calls the <tt/MTIOC/
ioctls itself instead of relying on the <tt/mt/ program to perform
tape operations.

</descrip>

The <tt/ftape-manual/ contained in the <tt/ftape-doc/ package contains
much more detailed information about <tt/ftape`s/ file system
interface as well as implementation notes which by far exceed the
scope of this HOWTO. See <ref id="getting" name="Getting Ftape"> for
informations about where to obtain the manual.



<sect1>Installing the driver with v2.0.x and earlier kernels<label id="inst20"><p>

The following section provides some useful information to get you
going with the installation of v4.x which is <bf/not/ shipped with the
kernel source tree yet but has to be downloaded separately, see the
section <ref id="getting" name="Getting ftape"> above.

Once you've downloaded the source code (probably
<tt/ftape-4.02-tar.gz/), untar it.  You can do this by determining what
directory you want the source code to be located in.  I recommend
<tt>/usr/src/</tt> or <tt>~/src</tt>.  When the tar file is extracted,
it will dump everything into a <tt/ftape-4.02/ subdirectory, so that
you'll end up, in the example I've given, with something like
<tt>/usr/src/ftape-4.02</tt> or <tt>~/src/ftape-4.02</tt>.

<bf/NOTE:/ you cannot compile <tt/ftape-4.02/ into your v2.0.x
kernel. Instead, configure your kernel to <bf/not/ compile the
<tt/ftape/ driver and follow the installation instructions in the
<tt/ftape-4.02/ distribution and install <tt/ftape-4.02/ as a module.

Read the <tt/README/ file.  The <tt/README/ is required reading.  It's
the top of the tree, so to speak.  If there are specific files that
the <tt/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 <tt/README/ files and the <tt/INSTALL/ file.

Afterwards you need to edit the <tt/MCONFIG/ file and configure you
package according to your hardware. The <tt/MCONFIG/ file contains lots
of explanations so it should be fairly easy to go along with it.

However, most of the hardware configuration can be done via setting
parameters during module load time so most parameters specified in the
file <tt/MCONFIG/ simply give the default configuration, but you don't
need to recompile the driver to change IO addresses or interrupt
settings. The file <tt/INSTALL/ and the file <tt>modules/insert</>
contain examples how to specify the proper module parameters when
loading the kernel modules, so I won't go into further detail here.

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

<!-- More detailed information will be contained in the <tt/ftape-doc/ -->
<!-- package which unluckily isn't ready at the time of this writing. -->

<sect1>Installing the driver with v2.1.x and later kernels<p>

<comment>
Maybe <tt/ftape-4.02/ will be included into the v2.2.x kernel, but
this isn't clear at the time of this writing. This HOWTO will be
revised appropriately when this has become clear. So long you have to
refer to the previous section <ref id="inst20" name="Installing the
driver with v2.0.x and earlier kernels"> and disregard the contents of
this section.
</>


The Linux kernel v2.1.x and later already include <tt/ftape-4.x/ so you
don't need to download the <tt/ftape-4.x/ kernel driver package.

<tt/ftape-4.x/ as included in the v2.1.x versions of the kernel can be
completely configured using the kernel configuration menus (either with
<tt/make menuconfig/ or <tt/make xconfig/. Also, there is online help
available that documents each parameter setting which I won't repeat
here.

The various boot- and loadtime parameter settings are explained in the
file 

<tt>&lsqb;/usr/src/linux/&rsqb;Documentation/ftape.txt</>

of the Linux-v2.1.x and later kernel distributions.

<sect1>Following the development of the <tt/ftape/ driver<label id="tape-channel"><p>

If you want to follow the development of the <tt/ftape/ driver, you
should subscribe to the Linux Tape mailing list
<tt/linux-tape@vger.rutgers.edu/. To do so you need to send an email
saying `<tt/subscribe linux-tape/' (<em>in the body</em>) to
<tt/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. <bf/Store this email in a safe
place/. Please.

Please note that I do not, repeat <bf>DO NOT</bf>, 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).


<sect1>Mixing <tt/ftape/ and floppies<p>

If you use your floppy tape drive with the standard FDC then the floppy
drive and the floppy tape drive cannot run concurrently as they share
the same hardware, the FDC, and the <tt/floppy/ and the <tt/ftape/
driver do not talk to each other.  Thus, if you have mounted a floppy
and then try to access the tape drive, <tt/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.


<!-- ****** Care and Feeding of Tapes and Tape Drives ****** -->

<sect>The Care and Feeding of Tape and Tape Drives<p>


<sect1>Formatting<p>

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


<sect2>Can I format my tapes under Linux?<p>

Yes, you can, if you use <tt/ftape-3.04d/ or above. To format a floppy
tape cartridge you need a user level tool called <tt/ftformat/ as well
which is contained in the <tt/ftape-tools/ distribution (see section
<ref id="getting" name="Getting ftape">).

The <tt/ftape-tools/ package comes with its own manual, so I do not need 
to repeat here how to use <tt/ftformat/.

<sect2>Which formatting programs can I use under DOS?<p>

The following are known to work:

<itemize>
<item> Colorado Memory System's software (<tt/tape.exe/)
<item> Conner Backup Basics v1.1 and all Windows versions
<item> Norton Backup
<item> QICstream version 2
<item> Tallgrass FileSecure v1.52
<item> Escom Powerstream 3.0 (<tt/qs3.exe/ -- QICstream v3?)
</itemize>

These programs are known to be more or less buggy:

<itemize>
<item> Conner Backup Basics 1.0
<item> Colorado Windows tape program
<item> CP Backup (wastes tape space, but is OK apart from that)
</itemize>

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,
<tt/ftape/ detects this, and will work around it.  Dennis T. Flaherty
(<tt/&lt;dennisf@denix.elk.miles.com&gt/) 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. <tt/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 (<htmlurl
url="mailto:heine@math1.rwth-aachen.de"
name="&lt;heine@math1.rwth-aachen.de&gt">), so I can update the list.


<sect1>Retensioning<p>

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.

<sect1>Drive Cleaning<p>

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 <htmlurl url="mailto:nealf@rcs.ee.washington.edu" name="Neal
Friedman"> for the explanation and suggestion that this information be
included in the HOWTO.

<sect1>Repairing de-spooled cartridges<p>

In rare occasions it can happen that the tape drive doesn't detect the
<bf/EOT/ (End Of Tape) markers correctly. These markers are simply
holes in the tape which are detected by the tape drive with means of a
little photo-transistor (or the like).

The manual of your tape drive will probably give you proper hints how
to clean those EOT detectors.

However, if the EOT detection fails, then the tape drive despooles the
cartridge because the tape isn't glued to the wheels, but hold by
friction only.

There are detailed instructions how to fix such a despooled tape at
the Iomega WWW pages at

<htmlurl url="http://www.iomega.com/support/techs/ditto/3006.html"
name="http://www.iomega.com/support/techs/ditto/3006.html">

and at the Hewlett Packard WWW pages at

<htmlurl url="http://www.hp.com/isgsupport/cms/docs/lpg12020.html"
name="http://www.hp.com/isgsupport/cms/docs/lpg12020.html">

If the pages shouldn't be in the exact locations as given above, then
please try to browse a little bit through the web pages of HP or
Iomega until you find the needed information.

<!-- ****** Supported and unsupported hardware ****** -->

<sect>Hardware support<p>

<sect1>Supported tape drives<label id="supp_drives"><p>

All drives that are both QIC-117 compatible <em>and</em> 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). Iomega Ditto 2GB
and Ditto Max drives are supported, too, though they no longer conform
to the QIC standards in every respect. Some parallel port tape drives
are supported as well.

Some of the comments given below about possible problems with certain
tape drives are very old, and I don't have access to all of the
hardware, so I couldn't check everything.

Some of the reports below have been commented by me
(&lt;heine@math1.rwth-aachen.de&gt;) like this:

<quote>
This is a comment.
</>

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

<descrip>
<tag/Alloy Retriever 250/<p>

<tag/Archive 5580i, XL9250i/<p>

<tag/Colorado DJ-10, DJ-20 (aka: Jumbo 120, Jumbo 250)/<p>

<tag/Colorado 1400/

&lt;kosowsky@bellini.harvard.edu&gt reported a problem doing a 1G
backup using taper.

<tag/Colorado Trakker parallel port tape drive/<P>

Support added by Jochen Hoenicke
&lt;Jochen.Hoenicke@Informatik.Uni-Oldenburg.DE&gt;.

<tag/HP Colorado T1000/

<quote>
The problem reports are probably totally out-dated. In particular, the
<tt/zftape/ the people talk about doesn't exist any more, and the
<tt/ftape/ driver is the very <tt/ftape-2.08/.
</quote>

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.
(&lt;millner@millner.bevc.blacksburg.va.us&gt)

Problems have been reported with the drive continually stopping and
starting with zftape (&lt;75104.1756@compuserve.com&gt).  This appears
to be a problem with the tape going too fast for the computer; the DMA
buffers are getting flushed before 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
(&lt;millner@millner.bevc.blacksburg.va.us&gt).

<tag/Conner C250MQ(T)/

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

<quote>
Write errors need not be caused by the tape drive, but also by bad
tape cartridges. Frequent repositioning can be caused by bad
cartridges, too, but can also be caused by overrun errors which would
indicate that the FDC and DMA controller have problems to talk to each
other.
</>

<tag/Conner TSM420R, TSM850R/

The 400 and 800 models only work with TR-1 tapes.

<quote>
I don't know whether it was meant that named drives doesn't work with
ordinary 120MB DC-2120 cartridges, or that TR-3 tapes can't be
read. The tape drives weren't designed for the latter. So what.
</>

<tag/Conner TST3200R/

Works with TR-3 tapes at 1Mbps (ie. 1600M capacity only).  Wirks with
QIC-WIDE 400M tapes (Sony 5122's?)  (&lt;chris@cs.wmich.edu&gt).
Works with TR3, QIC-3010, and QIC-3020 tapes.  Comes with a 2MB FDC
which the Promise 2300+ 1Mbps controller works
(&lt;kjh@pollux.usc.edu&gt).

Reported that the floppy disk can no longer read low-density floppies.
May have to fiddle with IRQ/ports/dma channels
(&lt;chris@yakkocs.wmich.edu&gt).

<quote>
The TST3200R works well with <tt/ftape/.
</>

<tag/Conner TST800R/

The TST800R works with TR-1, Sony QW5122F (210M) and DC2120 tapes.

<quote>
Works well with <tt/ftape/ since <tt/ftape-2.07/ at least. Used it
myself until the drive died with a melted transistor. Probably caused
by over-heating it previously.
</>

<tag/Conner CTT3200/<p>

The CTT3200 is supposedly identical to the Iomega Ditto 3200.  It
works with the supplied 2Mbps controller, but reported not to work
under DOS on some machines. (&lt;jmorris@dtx.net&gt)

<tag/Conner 1.7G Tapestor (TSM1700R)/<p>

Works with QIC-WIDE tapes (&lt;pschmidt@slip.net&gt).  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) (&lt;ttait@tiac.net&gt).  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
(&lt;ttait@tiac.net&gt).

<quote>
No recent informations available
</>

<tag/Escom or Archive (Hornet) 31250Q/<p>

<tag/Exabyte EXB-1500/

Work with QIC-3010 tapes.

<tag/Exabyte TR-3/

<tag/Irwin 80SX, Insight 80Mb/<p>

<tag/Iomega 250/<p>

<tag/Iomega Ditto Tape Insider 420, 1700/<p>

<tag/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. (Kevin Johnson
&lt;kjj@pobox.com&gt;).

<quote>
Refer to the file <tt/MCONFIG/ of recent <tt/ftape/ distributions for
other suggestions for ioport, irq and DMA channel.
</>

May require the having <tt/&lcub;0x08882, 80, wake_up_colorado, "Iomega
3200"&rcub;,/ added to <tt/vendors.h/ on older versions of <tt/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 (&lt;erwin@box.nl&gt).  Also, after the first
access, the next use of the tape says it is write protected
(&lt;erwin@box.nl&gt, &lt;M.J.Ammerlaan@dutiwy.twi.tudelft.nl&gt).

There has been one report of a problem where the tape got wound off
the end of the spool.

<quote>
This may be caused by a dirty EOT sensor, and need not be a real
hardware bug (except when it was a bug that dirtied the EOT sensor
...)
</>

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

<quote>
Should have been fixed somewhere between <tt/ftape-3.00/ and
<tt/ftape-4.00/. Unluckily, the fast-skipping facilities of all Iomega
floppy tape drives are <bf/really/ poor. Recent <tt/ftape/ versions
work around this problem. I suggest getting the latest version of the
<tt/ftape/ driver when you experience this problem.
</>

<tag/Iomega Ditto 800 Insider/

Works with Travan TR1, TR2, or DC2120 tapes
(&lt;klein@informatik.uni-rostock.de&gt).

<tag/Iomega Ditto 2GB/

Support added by Jochen Hoenicke
&lt;Jochen.Hoenicke@Informatik.Uni-Oldenburg.DE&gt; to <tt/ftape-3.xx/
and later.

Can't format cartridges, writing is only possible with special Ditto
2GB cartridges (hardware limitation, not a lacking feature of
<tt/ftape/).

<tag/Iomega Ditto Max/<p>
<tag/Iomega Ditto Max Pro/

Supported since <tt/ftape-4.00/. Thanks to Tim Jones
&lt;tjones@estinc.com&gt;.

Can't format cartridges, writing is only possible with special Ditto Max
cartridges (hardware limitation, not a lacking feature of <tt/ftape/)

I wasn't able to get the Ditto Max to work with any other device than
<tt>/dev/[n]qft0</tt>. I don't know whether this is a feature of the
Ditto Max or the Ditto EZ controller I had plugged the Ditto Max into.

<comment>
You don't need to buy a <tt/Ditto Max Pro/ to use the 5/10GB
cartridges. With <tt/ftape/ there is no real difference between the
<tt/Ditto Max/ and the <tt/Ditto Max Pro/.
</>

<tag>Iomega Ditto 800/3200/2GB/Max/Max Pro Easy (parallel port)</tag>

Supported since <tt/ftape-4.00/ with the <tt/bpck-fdc/ FDC driver.

<tag/Mountain FS8000/<p>

<tag/Reveal TB1400/<p>

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

<quote>
The mentioned <tt/ftape/ driver versions are out of date. If you still
have such a beast try the more recent versions of the <tt/ftape/
driver.
</>

<tag/Summit SE 150, SE 250/<p>

<tag/Tallgrass FS300</tag>

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

<tag/Teac 800/<p>

<tag/Memorex tape drive backup system/<p>

<tag/Wangtek 3040F, 3080F/<p>

</descrip>

You can always check out the newest list of drives that are recognised
by <tt/ftape/, by looking in the file <tt/vendors.h/ in the <tt/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).

<quote>
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 (<tt/&lt;heine@math1.rwth-aachen.de&gt/).
</>

<sect1>Supported special controllers<p>

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

<itemize>
<item> Colorado FC-10, FC-20
<item> Mountain MACH-2
<item> Iomega Tape Accelerator II
<item> 2Mbps controllers (using the i82078-1 fdc)
<item> Iomega Ditto EZ 4Mbps PnP controller
</itemize>

<sect2>Colorado FC-10, FC-20<p>

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

<sect2>Mountain MACH-2<p>

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

<sect2>Iomega Tape Accelerator II<p>

To use the Iomega Tape Accelerator II (<bf/not/ to be mistaken as the
Iomega Ditto Dash!), use <tt/-DMACH2/, and set the right settings for
I/O base, IRQ and DMA.  This works (by the empirical testing of Scott
Bailey <htmlurl url="mailto:sbailey@xcc.mc.xerox.com"
name="&lt;sbailey@xcc.mc.xerox.com&gt">), with at least
<tt/ftape-2.02/.

<sect2>Iomega Ditto Dash and other 2Mbps controllers<p>

The Iomega Ditto Dash, and all other known 2Mbps controllers, use the
Intel 82078-1 chip, which can run at 2Mbps. This is supported properly
since <tt/ftape-3.00/.

<sect2>Iomega Ditto EZ PnP controller<p>

This controller requires the use of e.g. the <tt/isapnptools/ package to 
configure it. You may get it from

<htmlurl url="http://www.roestock.demon.co.uk/isapnptools/"
name="http://www.roestock.demon.co.uk/isapnptools/">

The controller will cause too many overrun errors when used at the
highest possible speed of 4Mbps. Neither Tim Jones
&lt;tjones@estinc.com&gt; nor I &lt;heine@math1.rwth-aachen.de&gt;
have been able to find but a single system which could run the
controller at 4Mbps. 3Mbps seems to  be fine.

If you configure the Ditto EZ to use DMA 2 (the DMA channel used by
the floppy controller) then your floppy drive will no longer work. It
doesn't help to disable the controllers DMA gate (as is the case with
other hight speed controllers) so this can't be helped from inside
<tt/ftape/.

<sect1>Unsupported tape drives<label id="unsupp_drives"><p>

<itemize>
<item> Some parallel port floppy tape drives still not work. Others do.
<item> Irwin AX250L / Accutrak 250. (not a QIC-80 drive)
<item> IBM Internal Tape Backup Unit (identical to the Irwin AX250L drive)
<item> COREtape light
</itemize>

The Irwin AX250L (and the IBM Internal Tape Backup Unit) does not work
the <tt/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.

<sect1>Using an external tape drive with <tt/ftape/<p>

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 <tt/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 <tt/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
<tt/ftape/'s point of view, they are identical.

<itemize>
	<item> Pins 20-37: GROUND
	<item>	1: +12 Volt (POWER)
	<item>	2: +12 Volt return (GROUND)
	<item>	3: +5 Volt return (GROUND)
	<item>	4: +5 Volt (POWER)
	<item>	5: 2
	<item>	6: 8
	<item>	7: 10
	<item>	8: 12
	<item>	9: 14
	<item>	10: 16
	<item>	11: 18
	<item>	12: 20
	<item>	13: 22
	<item>	14: 24
	<item>	15: 26
	<item>	16: 28
	<item>	17: 30
	<item>	18: 32
	<item>	19: 34
</itemize>

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.


<sect1>PCI motherboards and <tt/ftape/<label id="pci-boxes"><p>

Unfortunately, some PCI motherboards cause problems when running
<tt/ftape/.  Some people have experienced that <tt/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 <tt/README.PCI/
file in the <tt/ftape/ distribution.

<quote>
A floppy disk controller needs the ISA bus DMA controller for its
memory transfers. Seemingly the ISA DMA controller doesn't get
control over the memory bus often enough on some PCI based systems.
</>


<!-- ******* ****** Backing up and restoring data ****** ****** -->


<sect>Backing up and restoring data<p>

This section describes some simple uses of <tt/tar/ and <tt/mt/. Other
examples can be found in the <tt/ftape-manual/ of the <tt/ftape-doc/
package. The <tt/ftape-tools/ contains some simple automated
<tt/DejaGnu/<footnote>Package for writing automated tests.</>
test-suites. See section <ref id="getting" name="Getting ftape"> for
informations about where to download those additional packages from.

<sect1>Writing an archive to a tape<label id="write-backup"><p>

You can use `<tt/tar/', `<tt/dd/', `<tt/cpio/', and `<tt/afio/'. You
will need to use `<tt/mt/' to get the full potential of your tapes and
the <tt/ftape/ driver.  For a start I'd recommend using `<tt/tar/', as
it can archive lots of directories and let you pick out separate files
from an archive.  <tt/cpio/ creates smaller archives and is more
generally more flexible than <tt/tar/, but is missing some features
like volume labels.  `<tt/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
<tt/gzip/ped <tt/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.

There are more links pointing to backup software at
<htmlurl
url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"> in the
<tt/software/ section of that page.

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

<tscreen><verb>
	# cd /usr/src
	# tar cf /dev/ftape linux
</verb></tscreen>

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

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

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

<sect1>Restoring an archive<p>

OK, let us restore the backup of the kernel source you made in section
<ref id="write-backup" name="Writing an archive to a tape"> above.  To
do this you simply say

<tscreen><verb>
	tar xf /dev/ftape
</verb></tscreen>

If you used compression, you will have to say

<tscreen><verb>
	tar xzf /dev/ftape
</verb></tscreen>

When you use compression, <tt/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.


<sect1>Testing the archive<p>

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

<tscreen><verb>
	tar df /dev/ftape
</verb></tscreen>

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

<sect1>Putting more than one backup on a tape<p>


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

Programs like <tt/tar/ and <tt/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. <tt/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 <tt/tar/ or <tt/cpio/
with <tt/mt/ does the trick.

By using the <tt/nqft[0-3]/ (<tt/nftape/) device, you can use
`<tt/mt/' to position the tape the correct place (`<tt>mt -f
/dev/nqft0 fsf 2</tt>' means step over two ``file marks'', i.e.
<tt/tar/ files) and then use <tt/tar/ or <tt/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.

<itemize>

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

<item> Issue an End-of-Tape command to the NON-rewinding device.

<tscreen><verb>
	mt -f /dev/n???? eof
</verb></tscreen>

The tape should now be positioned at the End-of-Data (<bf/EOD/). 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 `<tt/mt eof/' may be faster on QIC tapes.

<item> The next tape operation will start at the EOD mark.  If you
perform a write, it will append a new `file'.  If you perform a read it
will fail with EOF.  The EOD mark on most tape formats is actually two
consecutive EOF marks, however, since version 3.xx <tt/ftape / uses the
volume table as specified in the <tt/QIC-113/ standard to emulate file
marks, thus there aren't two consecutive file marks at EOD. Writing the
EOF marks is handled by either the device driver or the hardware when a
close() is performed.

<item> Here's where you write the actual data to the tape.

<item> Here's the important part. <bf>Now rewind the tape</bf>.  Both
<tt/ftape/ caches some information that belongs in the header segments
on the tape and update those header segments <bf>only when the tape is
rewound</bf>.  This caching is necessary because rewinding the tape and
updating the header segments takes a conspicuous 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.

</itemize>


<sect1>Appending files to an archive<p>

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

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


<sect1>Mount/unmounting tapes<p>

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
`<tt/tar/' command (or whatever you use to access the tape with).



<!-- ****** ****** Creating an emergency boot floppy ****** ****** -->


<sect>Creating an emergency boot floppy for <tt/ftape/<p>

<comment>
As of the time of this writing (August 1998) I remember that I have read
about several emergency disk sets in the <bf/c.o.l.a/
(<tt/comp.os.linux.announce/) news group since the time this section has
been written. Some of those packages actually might produce rather
sophisticated emergency boot floppy sets. Please check out yourself.  I
didn't try to create an emergency boot floppy with recent versions of
<tt/ftape/.
</comment>


This section was written by Claus T&oslash;ndering
<tt/&lt;ct@login.dknet.dk&gt/.

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 <htmlurl url="mailto:grahamc@zeta.org.au"
name="&lt;grahamc@zeta.org.au&gt">.  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:

<itemize>
<item>	You don't really need <tt>/etc/init</tt>, <tt>/etc/inittab</tt>, 
	<tt>/etc/getty</tt>, and <tt>/etc/rc.d/*</tt> on your floppy disk.  If
	Linux doesn't find <tt>/etc/init</tt>, it will start <tt>/bin/sh</tt>
	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.
<item>	Find a small version of <tt>/bin/sh</tt>.  They are frequently
	available on the boot floppies that come with a Linux distribution.
	This again will give you extra space.  I'd suggest <tt/ash/, which
	is extremely small (approx 62Kbytes), and yet very <tt/bash/
	compatible.
<item>	The <tt>/etc/fstab</tt> you include on your floppy disk should look
	something like this:
	<tscreen><verb>
	/dev/fd0	/		minix	defaults
	none		/proc		proc	defaults
	/dev/hda	/mnt		ext2	defaults
	</verb></tscreen>
	Once you have booted from your floppy, give the command:
	<tscreen><verb>
	mount -av
	</verb></tscreen>
<item>	Make sure your floppy drive is not mounted when you access the
	streamer tape!  Otherwise you may get the following error message:
	<tscreen><verb>
	Unable to grab IRQ6 for ftape driver
	</verb></tscreen>
	This means that you <bf>MUST</bf> 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:
	<enum>
	<item>	You place <tt/tar/ (or <tt/cpio/ or <tt/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.) 
	<item>	Before you start restoring from tape, copy <tt/tar/ (or
		<tt/cpio/ or <tt/afio/ or whatever) to your hard disk
		and load it from there.
	</enum>
<item>	Apart from your backup program, you will probably need <tt/mt/ on
	your root floppy as well.
<item>	Make sure your ftape device (typically <tt>/dev/nqft0</tt>) is present
	on your boot floppy.
<item>	Finally: <bf>TRY IT OUT!</bf> 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.
</itemize>


<!-- ****** Ftape-FAQ, wordly included. Keep in sync with the separate
FAQ distribution ****** -->

<sect>Frequently Asked Questions<p>

<comment>
This is the literal inclusion of the Ftape Frequently Asked questions
collection which is maintained by <htmlurl
url="mailto:jo@correct.nl" name="Johan De Wit
&lt;jo@correct.nl&gt;"> and which may be viewed on the web at
<htmlurl url="http://www.correct.nl/~ftape"
name="http://www.correct.nl/~ftape">.  As Linuxdoc SGML doesn't include
sub-sub-sections into the table of contents, I have prepended the word
<tt/FAQ/ to the sections of the original FAQ document.
</comment>

<bf>This FAQ collection might be slightly out of data as it was
collected while version 3.04d of the <tt/ftape/ driver was the newest
one. If any answer given in the FAQ contradicts any other statement of
this HOWTO, then please disregard the answer in the FAQ and drop me
(&lt;heine@math1.rwth-aachen.de&gt;) as well as the maintainer of the
<tt/Ftape-FAQ/ (Johan De Wit &lt;jo@correct.nl&gt;) a note
</bf>

<!-- ****** Include the FAQ here, strip the trailing and leading
garbage and prepend the word "FAQ: " to each section ****** -->

You might encounter references to the following addresses while reading   
this document:

<itemize>
<item>The maintainer of the Ftape FAQ :

	<htmlurl url="mailto:jo@correct.nl" 
	name="Johan De Wit &lt;jo@correct.nl&gt;">
<item>The Ftape maintainer :

	<htmlurl url="mailto:heine@math1.rwth-aachen.de" 
	name="Claus-Justus Heine &lt;claus@momo.math.rwth-aachen.de&gt;">
<item>The Ftape Home Page :

	<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/" 
	name="&lt;http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/&gt;"> 

<item>Mirrors of the Ftape Home Page :
<p>
	<htmlurl url="http://www.torque.net/ftape/" 
	name="&lt;http://www.torque.net/ftape/&gt;"> 
<p>
Thanks to <htmlurl url="mailto:grant@torque.net" 
		name="Grant R. Guenther &lt;grant@torque.net&gt;">
<p>
	<htmlurl url="http://www.info-systems.com/ftape/" 
		name="&lt;http://www.info-systems.com/ftape/&gt;"> 
<p>
Thanks to <htmlurl url="mailto:jc@info-systems.com" 
		name="Jakob Curdes &lt;jc@info-systems.com&gt;">
<p>
	<htmlurl url="http://www.newwwave.net/~joshg/ftape/" 
		name="&lt;http://www.newwave.net/~joshg/ftape/&gt;"> 
<p>
Thanks to <htmlurl url="mailto:joshg@newwave.net" 
		name="Josh Goins &lt;joshg@newwave.net&gt;">

<item>The Ftape HOWTO :

	<htmlurl url="http://sunsite.unc.edu/LDP/HOWTO" 
	name="&lt;http://sunsite.unc.edu/LDP/HOWTO&gt;"> 

<item>The Ftape Mailing List :

	<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
	name="&lt;linux-tape@vger.rutgers.edu&gt;">
</itemize>  

There is surely quite a lot missing. Please feel free to improve this FAQ.   
The preferred way of doing this is to post to the 
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
name="Ftape Mailing List">  
in case you have a question that isn't answered here.

Also, if you are already reading the list regularly and have the impression   
that some questions occur again and again, feel free to send that question   
and possibly an answer in the format indicated below to the 
<htmlurl url="mailto:jo@correct.nl"
name="maintainer"> 
of the <em/Ftape FAQ/ AND to 
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
name="Ftape Mailing List">. 

If you make FAQ related postings, then please DON'T FORGET to prepend the   
word "<bf/[FAQ]/" to the subject of your posting. Please don't add the word  
"FAQ" to the subject if you post something that isn't related to the FAQ.

That's all for now.

<htmlurl url="mailto:heine@math1.rwth-aachen.de" 
name="Claus-Justus Heine">.

<sect>FAQ: "Compiling and installing Ftape" related questions !<p>

<sect1>What Ftape version should I use?<p>

Always the latest stable version which is _supposed_ to be available from
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes"
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">
and
<htmlurl url ="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">

At time of this writing the latest stable version is <tt/ftape-4.02/.

&lt;answer from Claus Heine&gt;
<sect1>I'm having problems getting my XYZ drive to run under the 2.0.xx kernel with the built-in driver.  How do I fix this?<p>

The default version of <em/Ftape/ included in the 2.0.xx kernel sources is   
2.08 or 2.09 and is very out of date.  Please update the <em/Ftape drivers/   
to the latest from the 
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="Ftape Home Page">.

&lt;answer from Tim Jones&gt;
<sect1>I'm running Linux/SMP and the system just freezes when trying to access the Ftape devices!<p>

You need to add <tt/-D__SMP__/ to the <tt/KERNEL_OPT/ variable in the
file <tt/MCONFIG/. In newer <tt/ftape/ versions you only need to
uncomment a certain line in the <tt/MCONFIG/ file.

&lt;answer from Claus Heine&gt;

<sect1>Why does depmod complain about "undefined symbols"?<p>

Ignore the depmod error messages. The problem is that the <em/Ftape modules/   
have to be compiled without the version checksum feature (i.e.   
<tt/CONFIG_MODVERSIONS/) with 2.0.&ast; kernels. This causes no problem, even   
when the modules are used with a kernel that has support for this feature;   
only that <tt/depmod/ wrongly complains about undefined symbols. Ignore the   
complaints of <tt/depmod/ and try to insert the modules despite of these   
complaints: 
<tscreen><verb>
modprobe zftape
</verb></tscreen>
If this fails, something is wrong.

&lt;answer from Claus Heine&gt;

<sect1>"insmod" says the kernel version is wrong<p>

The <tt/insmod/ program can check the kernel version against the
version that <em/Ftape/ was compiled for in two ways: It can directly
compare the kernel version number recorded in the <em/Ftape module/ against
the version of the running kernel, or, if both the kernel and
<em/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 <tt/insmod/ allows you to "force" insertion of
a module into the kernel, even though the version string is incorrect.

&lt;from the Ftape-Howto&gt;

<sect1>"insmod" says that kernel 1.2.0 and 1.2.0 differ<p>

Did you remember to apply the <tt/ksyms.c/ patch to the kernel?  If
not, read the <tt/README.linux-1.2/ file in the source distribution.

&lt;from the Ftape-Howto&gt;

<sect1> Trying to compile Ftape gives me the error "modversions.h: no such file or directory"<p>

The <tt/modversions.h/ file is created when the kernel is compiled  
with the configuration item <tt/CONFIG_MODVERSIONS/ turned on.  With  
this option enabled, the file will be created during the <tt/make dep/  
step.

One more handy tip is that a <tt/make mrproper/ will remove  
<tt>/usr/include/linux/modversions.h</tt>.  You will need to reconfig  
the kernel and do a <tt/make dep/ to get the file back.  

&lt;from the Ftape-Howto&gt;

<sect1>What is this versioned symbols stuff anyway?<p>

When you say `yes' to <tt/CONFIG_MODVERSIONS/ during `<tt/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  
<tt/insmod/ to detect whether the definition of a variable or function  
in the kernel has changed since the time when <em/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 <tt/CONFIG_MODVERSIONS/ in the kernel, make sure you have  
<verb>
-DMODVERSIONS -include /usr/include/linux/modversions.h
</verb>
uncommented in the MODULE_OPT line in the <em/Ftape/ Makefile.  Conversely,   
if you do not have CONFIG_MODVERSIONS enabled, make sure you have it  
commented out.

&lt;from the Ftape-Howto&gt;

<sect1>I seem to be getting sftape instead of zftape. When I run "ftmt status" command, I get output that the Ftape docs says corresponds to sftape ( /dev/qft0: Invalid argument ). Why?<p>

There are (at least) two possible sources of the problem:
<itemize>
<item>
All Ftape-3.&ast; versions prior to 3.04 install the modules into
<tscreen><verb>
/lib/modules/misc
instead of
/lib/modules/uname -r/misc
</verb></tscreen>
As <tt/modprobe/ searches in <tt>/lib/modules/misc/</tt> last there might be   
an old <tt/ftape.o/ module floating around in <tt>/lib/modules/</tt><em>  
uname -r</em><tt>/misc</tt> which <tt/modprobe/ finds first (<tt/uname -r/   
stands for the kernel version).
Remove the old <tt/ftape.o/ module.
<item>
Your kernel has support for <em/Ftape/ compiled in. Reconfigure  
your kernel without support for <em/Ftape/ (<tt/CONFIG_FTAPE/) and  
recompile and install it.
</itemize>

&lt;answer from Claus Heins&gt;

<sect1>My Ditto DASH/FC-20/Exabyte Accelerator card works under Microsoft Windows, but I get a drive not found type of error in /var/log/messages when trying to use it under Linux.<p>

You are probably trying to use the same IRQ and DMA settings as your on-board  
FDC. This does not work in versions of <em/Ftape/ prior to 3.03b. Please   
update the <em/Ftape Drivers/ to the latest from the
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="Ftape Home Page">.

&lt;answer from Tim Jones&gt;

<sect1>Ftape DMA transfers gives ECC errors<p>

Sadly to say there are some SVGA cards and Ethernet cards that do not
decode their addresses correct.  This typically happens when the
<em/Ftape/ buffers are in the range <tt/0x1a0000/ to <tt/0x1c0000/.
Somehow, the DMA write cycles get clobbered and every other byte
written gets a bad value (<tt/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
<em/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 <em/Ftape/
software.

&lt;from the Ftape-Howto&gt;

<sect1>Help! I'm getting 'dmaalloc() failed' in my syslog file.<p>

You should only see this is you are trying to <tt/insmod/ the
<tt/ftape.o/ module.  Try running <tt/swapout/ first.  It is provided
with the standalone <em/Ftape/ source.  It doesn't appear in the
<em/Ftape/ source that's provided with the kernel.

Here's an example of how you can set your rc.local file to use it.

<tscreen>
<verb>
# 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
</verb>
</tscreen>

Please note that you won't have this type of problem if you compile
the <em/Ftape driver/ into the kernel.

&lt;from the Ftape-Howto&gt;

<sect1>Syslogd works overtime when running Ftape<p>

The compile-time options <tt/NO_TRACE/ and <tt/NO_TRACE_AT_ALL/ in <em/Ftape/  
control the amount of system logging.  Add whichever is appropriate to the
<tt/FTAPE_OPT/ line in the Makefile and recompile.
 
&lt;from the Ftape-Howto&gt;

<sect1>How do I change the trace-level?<p>

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.

<itemize>  
<item>0 Bugs  
<item>1 + Errors  
<item>2 + Warnings  
<item>3 + Information  
<item>4 + More information  
<item>5 + Program flow  
<item>6 + FDC/DMA info  
<item>7 + Data flow  
<item>8 + Everything else  
</itemize>

<enum>
<item>
Using insmod to change trace-level

If you are using the modules mechanism to load the <em/Ftape/  
driver, you can specify the tracing level as an option to the insmod  
command.
<tscreen><verb>
        /sbin/insmod ftape.o tracing=<tracing-level>
</verb></tscreen>
<item>
Using mt to change trace-level

The <em/Ftape/ driver has a hack in it that allows the <tt/fsr/ option  
in <tt/mt/ to be used to set the tracing level.  <tt/zftape/ does not  
have this hack.
<tscreen><verb>
        mt -f /dev/ftape fsr <tracing-level>
</verb></tscreen>
The use of the <tt/fsr/ command in <tt/mt/ is a <em>hack</em>,  
and will probably disappear or change with time.

<item>Recompiling to change trace-level

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

</enum>

&lt;From the Ftape-Howto&gt;

<sect1>I'm having problems with Ftape.  I'm using the latest version of Ftape from the Ftape Home Page and believe that I've located a real bug. What should I do?<p>

Check the 
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="Ftape Home Page">.
for an even newer version. Then check the FAQ contained in the that package   
if your problem is listed there. Next, try to check if the manual that comes   
with the <em/Ftape distribution/ mentions your problem.

There is no need to read the entire manual, simply check the "Concept Index"   
if it contains a keyword that might be related to your problem, then jump   
to the proper location in the manual.

If you are still convinced you've found a bug, then post a general question   
describing the problem to the 
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
name="Linux-Tape Mailing List">
, but do not attach your entire <em/Ftape/ error-log. If we've seen the   
problem before, we'll let you know where the resolution effort stands.  If   
we haven't, the 
<htmlurl url="mailto:heine@math1.rwth-aachen.de"
name="Ftape maintainer">
 will most likely request that you send him the entire <em/Ftape/ error-log  
(snipped from your system messages file).

&lt;answer from Tim Jones&gt;

<sect>FAQ: "Using Ftape" related questions !<p>

<sect1>How fast is Ftape ?<p>

You can achieve quite respectable backup and restore speeds with
<em/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 <em/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).


<sect1>When I write to some of my tapes, they seem to spend a lot of time "shoe-shining," or repositioning instead of streaming.  Is something wrong with my system?<p>

There has 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.

&lt;from the Ftape-Howto&gt;

Probably not. If you are backing up a large number of &lt; 2K files, you're   
just going to have to live with it.  In this event, the repositions are caused  
by file system access overhead. If you are backing up a normal system's files,  
this may be caused by slop or media stretching in the tape cartridge. By   
simply retensioning the tape, you should see this go away. Try  
<tscreen><verb>
ftmt -f /dev/zqft0 reten
</verb></tscreen>
to retension the tape. If retensioning doesn't solve this, and it's only   
happening on certain tapes, it might be wise to replace the tapes in question.

&lt;answer from Tim Jones&gt;

If you use afio as your backup tool you can set it to write a very large   
number of buffers in one hit by using the -c flag. Make it large enough so   
that you supply enough data for most of a single end-to-end pass over the tape.
For my system, the following streams quite nicely - stopping relatively few  
times per tape pass on an unloaded system:
<tscreen><verb>
find /usr/local -xdev -print | afio -o -v -f -b 10240 -c 800 /dev/qft0
</verb></tscreen>
In my case I'm writing 800 x 10240 bytes per tape write, i.e. about 8MB.   
haven't experimented that much with these settings - so someone might like   
to establish more optimal ones.

Presumably other backup utilities could be modified to use a similar technique.

&lt;answer by Michael Hamilton&gt;

GNU tar doesn't use buffering in this way. The commercial backup program   
"bru" is able to multi-buffer using shared memory; this works only when   
writing compressed archive with bru (regardless whether you use <em/Ftape's/   
builtin compression)

Another way to overcome the problem might be to use more dma buffers in the   
<em/Ftape kernel driver/ like:
<tscreen><verb>
mt -f /dev/qft0 setdrvbuffer &dollar;((6&ast;32786))
</verb></tscreen>
&dollar;((6&ast;32786)) should be expanded by your shell when using a Bourne  
compatible one. This has a negative impact on the system's memory pool:   
<em/Ftape's/ dma buffers cannot be used by any other part of the kernel nor   
by any other application. And kernel memory cannot be swapped out. If you   
decide to use this kind of multi-buffering then you should unload the driver   
as soon as it isn't needed any longer.

&lt;answer by Claus Heine&gt;

<sect1>Do I have to reboot to the DOS world to format tapes? <p>

Not if you are using the latest version of the <em/Ftape drivers/ from  the  
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="Ftape Home Page">.

To format a QIC-80, TR-1, TR-3, QICWide 3010 or 3020 tape, get the
latest version of <tt/ftape/ and the latest version of the
<tt/ftape-tools/ package (from the same location) and read the
documentation of the <tt/ftformat/ utility which is included in the
<tt/ftape-tools/ package.

<comment>
Do not try to format Ditto 2GB tapes.
</>
<comment>
Do not try to format Ditto Max or Max Pro tapes.
</>

&lt;answers from Tim Jones and Claus Heine&gt; 

<sect1>Is it possibly to format Ditto 2GB tapes with ftape?<p>

It isn't possible to format <tt/Ditto 2GB/ tapes with <tt/Ditto 2GB/
tape drive, and it isn't possible at all to re-format <tt/Ditto 2GB/
tapes in a way that they still can be used by a <tt/Ditto 2GB/ tape
drive.

This is a hardware limitation of the <tt/Ditto 2GB/ tape drive. It
can't be helped at the software level, i.e. it isn't <tt/ftape's/
fault.

<sect1>Is it possibly to format Ditto Max or Max Pro tapes with ftape?<p>

No, the <tt/Ditto Max/ can't format tapes.

This is a hardware limitation of the <tt/Ditto Max (Pro)/ tape drive. It
can't be helped at the software level, i.e. it isn't <tt/ftape's/
fault.

<sect1>Ftape detects more bad sectors than DOS on QIC-3020 tapes<p>

If you look at the difference, you will notice that <em/Ftape/
always detects 2784 sectors more than DOS.

The number that <em/Ftape/ reports is correct (of course <tt/:-)/. 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:

<quote>
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.
</quote>

This gives 12 tracks &ast; 2 &ast; 4 segments &ast; 29 sectors == 2784 sectors.

So <em/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.  (<em/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.

&lt;from the Ftape-Howto&gt;

<sect1>Is it ok that I'm not hearing the tape move when I do a fsf or a bsf with mt?<p>

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.

&lt;from the Ftape-Howto&gt;

<sect1>Why does my XYZ backup program complain about "Invalid argument" errors?<p>

<tt/zftape/ requires the data to be written in multiples of a fixed minimal   
block size. This is a very usual behavior for a tape device. There are three   
ways to get rid of those errors:
<itemize>
<item>
set <em/Ftape's/ block size to the block size used by the backup program. The example below works for "afio":
<tscreen><verb>
mt -f /dev/qft0 setblk 5120
</verb></tscreen>
<item>
If you don't want to use <em/Ftape's/ built in compression you can also use
<tscreen><verb>
mt -f /dev/qft0 setblk 0
</verb></tscreen>
to switch <em/Ftape/ to variable block size mode and be able to write the   
data in arbitrary portions to the tape (BUT: the builtin compression doesn't   
work with this setting). When you intend to use "KBackup" then this is the   
only way to make it work together with <em/Ftape/ (it _may_ work, don't know   
if it does)
<item>
tell your backup program about <em/Ftape's/ default block size of 10k (which   
is also the default of GNU tar). For "afio" you can use the following command   
line switch:
<tscreen><verb>
afio -b 10k ...
</verb></tscreen>
</itemize>

You may want to read the section "Tape blocks" of the manual (use its   
"Concept index" to directly jump to that section)

When using GNU tar's builtin compression with GNU tar versions prior to
tar-1.12 one needs to run tar with the <tt>--block-compress</tt> switch to
<tt>re-block</tt> the output to the tape.  Otherwise tar will compress the data 
it reads, and write it in arbitrary portions to the tape.

<tscreen>
<verb>
Example :

tar -czvf /dev/qft0 --block-compress /etc
</verb>
</tscreen>

<bf/WARNING:/
One shouldn't use tar's builtin compression with large backups as it makes the
entire data stream one huge compressed block.  If such archives are corrupted
right at the beginning it will be very difficult to recover.

&lt;answer by Claus Heine&gt;

<sect1>I/O errors and FDC - some explanations.<p>

When you get next messages, this could be interesting for you !

<itemize>
<item>
fdc-io.c (ft_handle_perpend) - Your FDC does not support QIC-3020.
<item>
Cannot write to /dev/qft0: I/O error
</itemize>

The explanations: 

"FDC" menas "Floppy Disk Controller". The
problem is that your floppy disk controller must be able to support
something that is called "perpendicular mode" to be able to read and
write QIC-3020/QIC-3010 cartridges (i.e. TR-3 cartridges). To my
knowledge all FDCs that are capable of at least 1Mbit/sec data
transfer rate also support "perpendicular mode" ("perpendicular"
refers to the direction of magnetization of the ferro-magnetic
particles on the tape).

This means that you need to purchase another FDC. Either look around
some computer stores and ask for an IO controller cards that is able
to support 2.88 Mb floppies (which imlies 1Mbit data transfer rate and
perpendicular mode).

Or get one of the so called "high speed" controllers that even support
2Mbit/sec data transfer rate. Those controllers are based on an Intel
82078 FDC. Iomega sells such a card under the name "Ditto Dash". I
think Exabyte sells their 2Mbit controllers separately, too, whereas
Seagate ships its TR-3 drives (i.e. the TST-3200) together with such a
controller.


&lt;answer from Claus Heine&gt;

<sect1>Why do I get "/dev/qft0: No such device" errors?<p>

I assume that the following is the problem:
The <em/Ftape/ module is loaded OK into the kernel:
<tscreen><verb>
/usr/src/ftape-3.03b-970603# lsmod
 Module         Pages    Used by
 ftape             22            0
</verb></tscreen>
but then this happens:
<tscreen><verb>
&dollar; ftmt -f /dev/qft0 status
ftmt: /dev/qft0: No such device
</verb></tscreen>

Solution
You need to load the <em/zftape.o/ module as well. With Ftape-3.&ast; the   
<em/ftape.o/ module doesn't implement the VFS interface. This is done by   
<em/zftape.o/.

&lt;answer from Claus Heine&gt;

<sect1>I get "device busy" when I make multiple backups on a tape using some script.<p>

The "device busy" messages can only occur while the <em/Ftape devices/ are   
still held open by some program. As soon as the close() system call has   
completed the busy flag is cleared. May be "bru" or some other program has   
still forked off a child that dies delayed?

Yes, this will reproduce the problem, it seems:
<tscreen><verb>
tar -cvvzf /dev/nqft0 --block-compress ; mt rewind
</verb></tscreen>
You can skip the "--block-compress" if using the most recent version  
of GNU tar.

However, this is not a bug of <em/Ftape/. It seems that the parent tar  
process exits before its child has closed the tape device. I know,  
however, from hacking the tar code ages ago, that tar properly waits  
for its parent to die.

However, the busy message simply means that the "busy" variable is  
still held at 1 (zftape/zftape-init.c). And this simply means that  
there still is a process hanging around that holds the tape device  
open. 

I think I have it (only for the case of tar 'cause I have the source
code.

If on uses tar with compression, then it forks a child which will
become the compressor bei execing  "gzip" or whatever. Before the call
to execlp() the child will fork off a grand child of its parent
tar. That grandchild will do the actual tape I/O.
<tscreen><verb>
tar - fork() - write to child tar
	|
      child tar - fork() - gzip (will pipe to grand child tar)
                    |
                  grand child tar - open archive.
</verb></tscreen>

Now, parent tar only waits for its child to die. gzip surely doesn't
wait for the grand child as the gzip is a result of an execlp().

What I don't know is whether the grand child should be implicitly
waited for by the parent tar, or if the wait() function also waits for
grand childs.

But this seems to be the problem: the parent tar already has exited
while its grandchild still is busy closing the archive. One hardly
will notice this problem if the close() happens fast (i.e. regular
files, block devices, also other tape devices?), but it isn't a bug in
<em/Ftape/, but either in the backup programs or in the kernel or maybe
libc exit code.

Don't know if the considerations above also apply to bru. If there is
no grandchild and the parent process properly waits for its childs
then there shouldn't be a problem.

&lt;answer from Claus Heine&gt

<sect1>How do I "..." with tar?<p>

These are really <tt/tar/ questions: Please read the <tt/man/ page and  
the <tt/info/ page.  If you have not got it either, try 
<tscreen><verb>
tar  --help 2>&amp;1 | less
</verb></tscreen>

If your version of <tt/tar/ is v1.11.1 or earlier, consider  
upgrading to v1.11.8 - This version can call <tt/GNU zip/ directly  
(i.e.: it supports the <tt/-z/ option) and has an elaborate help  
included.  Also, it compiles right out of the box on Linux.  

&lt;from the Ftape-Howto&gt;

<sect1>What block-size should I use with tar ?<p>

When using compression, and in all general, it can be a benefit to  
specify to <tt/tar/, that it should block the output into chunks.  
Since <em/Ftape/ cuts things into 29Kbyte blocks, saying `<tt/-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,  
<em/Ftape/ takes 29Kbytes of data, adds 3Kbytes of ECC parity, and  
writes 32Kbytes to the tape at a time.  For this reason, <em/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 <tt/ecc.c/ and  
<tt/ecc.h/ files, for an explanation of the code and a reference to a  
textbook on Reed-Solomon codes.

&lt;from the Ftape-Howto&gt;

<sect1>Where can I find the tar/mt/cpio/dd binaries - sources - manpages?<p>

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 <tt/ftp.funet.fi/, <tt/tsx-11.mit.edu/, and  
<tt/sunsite.unc.edu/).  In any case they can be fetched from the  
official GNU home site: <tt>prep.ai.mit.edu  
[18.71.0.38]:/pub/gnu</tt>.  The latest versions (as of September 12  
1996) are:

<tscreen><verb>
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)
</verb></tscreen>

They all compile out of the box on Linux <tt/v1.0.4/ / <tt/libc
v4.5.19/ / <tt/gcc v2.5.8/.

&lt;from the Ftape-Howto&gt;

<sect1>If I use tapers compression, is it a bad idea to use the compression with zftape, or would it be better to not use tapers compression, and let zftape do it?<p>

It is not bad as such to compress data twice (which would be the case
when using tapers compression together with <em/zftape's/ compression) but
it doesn't make any sense. You won't gain much further compression,
but only waste CPU cycles. 

Tapers compression should be quite safe, as taper compresses single
files; in contrast to <it/tar -czf .../ which makes the entire data
stream a large compressed block of data, which is really a bad thing
with serious backups as a single bad byte at the beginning of the
archive can make the entire archive unusable, well, it will be at
least quite difficult to recover.

&lt;Answer from Claus Heine&gt;

<sect1>How does zftape compression compare to say gzip -9?<p>

<it/gzip -9/ is better (i.e. one gains higher compression). <em/zftape's/
compression is comparable with the Un*x <it/compress/ program, but should
be faster, and is faster than <it/gzip/.

&lt;Answer from Claus Heine&gt;

<sect1>I don't trust compression, but hear that the sftape interface is going away. What should I do?<p>

Use the <em/zftape interface/, but don't load the <em/zft-compressor module/.  
The device then becomes <tt>/dev/qft0</tt>.

&lt;answer from Tim Jones&gt;

<sect1>Ftape says "This tape has no 'Linux raw format"<p>

You get this complaint if you haven't <em>erased</em> your freshly
formatted tape.  This is because <em/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
<verb>
mt -f /dev/nftape erase
</verb>

&lt;from the Ftape-Howto&gt;

<sect1>Can I exchange tapes with someone using DOS?<p>

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.

&lt;From the Ftape-Howto&gt;

<sect1>How does `mt eom' work when you've started overwriting a tape in the middle?<p>

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

&lt;from the Ftape-Howto&gt;
&lt;Answer from Claus Heine&gt;

<sect1>When I made backups before using taper, under the 2.0.29 ftape my drive didn't support fsf, under the new zftape it does, why would this be, and what exactly is fsf ?<p>

It probably didn't work before because you didn't use a 
<tscreen><verb>
mt -f /dev/rft0 erase
</verb></tscreen>
before writing data to the cartridge. THIS ISN'T necessary any more.

But, hey, what does <it/mt fsf/? Tape drives don't store files in the
sense that you can use <verb>cp somefile /dev/my_what_ever_tape</verb> 
or be able to mount the tape drive like you could mount a harddisk. 
You can't do nothing with a tape drive but write data to it in a sequential 
manner.

As this is quite inconvenient, somebody invented something which is
known under the name <it/file mark/ or <it/eof mark/ (eof == End Of
File). Those marks don't separate files that have been backed up to
the tape device, but only separate blocks of data (whatever data that
might be).

Normally, the kernel tape device drivers take care of writing file
marks when the tape device is closed, i.e.
<tscreen><verb>
tar -cf /dev/nqft0 /bin
tar -cf /dev/nqft0 /etc
mt -f /dev/nqft0 rewind
</verb></tscreen>
would result in a backup of all files under <it>/bin</it> and <it>/etc</it>. When
the first <it/tar/ finishes, the kernel driver will take care of writing
a file mark to the tape at the current tape position, and when the
second <it/tar/ process has finished, another file mark is written to the
tape cartridge at that position.

Now, the sense of those file marks is, that it is possible to skip
between different archives on the tape more quickly than would be
possible with reading the data back.

The commands to do that are:
<descrip>
<tag/mt fsf/fast skip to the next file mark towards EOT (End Of Tape)
<tag/mt bsf/fast skip to the next file marks towards BOT (Begin Of Tape)
</descrip>
Thus, to extract the second archive in the example above, one doesn't
need to read the first archive back, but can proceed as follows:
<tscreen><verb>
mt -f /dev/nqft0 rewind
mt -f /dev/nqft0 fsf
tar -xvf /dev/nqft0 
</verb></tscreen>

&lt;Answer from Claus Heine&gt;

<sect1>What exactly is the difference between ftape, and zftape?<p>

When <em/Ftape/ was young there were two versions of the floppy tape
driver, one of them was called <em/zftape/ because of its built-in
user-transparent on-the-fly compression. Whether such a thing is a
feature or a bug ('cause this needn't be done in kernel space) is
another question. However, the ioctl interface and file mark handling
provided by <em/zftape/ was much better and had less bugs. And <em/zftape/
allows to use floppy tape cartridges with different OS. Well, you
can't exchange data, but <em/zftape/ won't overwrite volumes created by
your Windoze program, and vice versa.

Nowadays, <em/Ftape/ is name of the entire floppy tape driver package AND
<it/ftape.o/ is the file-name of the kernel module that implements the
low-level hardware support. <em/zftape/ has ceased to exist as a separate
package, but the new <em/Ftape/ versions (since ftape-3.00) contain a
<em/zftape.o/ module that needs to be loaded on top of <em/ftape.o/
(i.e. you need to load BOTH modules to be able to access your floppy
tape drive) and implements the file system interface and the advanced
(?) features of the previous verions <em/zftape/.

&lt;Answer from Claus Heine&gt;

<sect1>What is the difference between a rewinding, and non rewinding drive?<p>

Well, the rewinding tape devices rewind the tape to BOT (Begin Of
Tape) when the device is closed, i.e.
<tscreen><verb>
tar -cvf /dev/qft0 /bin
</verb></tscreen>
will rewind the tape cartridge when the tar job has finished. In contrast, 
<tscreen><verb>
tar -cvf /dev/nqft0 /bin 
</verb></tscreen>
will NOT rewind the tape cartridge and leave the tape R/W head at its
current position.

Rewinding devices should be used when performing a single backup,
non-rewinding devices can be useful when doing multiple backups as one
doesn't need to space to EOM (End Of recorded Media) before appending
another archive.

Non-rewinding devices MUST be used when sending any of the tape motion
command to the tape drive, such as 
<tscreen><verb>
mt -f /dev/nqft0 fsf
</verb></tscreen>
, because when the <it/mt/ process finishes then the tape device is closed  
which would result in rewinding the cartridge with the rewinding devices.

&lt;Answer from Claus Heine&gt;

<sect1>Can someone tell me how to use mt to rewind my TR-3 drive one record using zftape record, so I can verify it?<p>

Well, it depends. If the tape is still positioned inside the volume  
just written, "mt bsf 1" (or equivalently "mt bsf") will backspace  
just to the beginning of that volume (this is how "tar --verify"  
works). If the tape is already positioned AFTER the filemark that  
marks the end of the last written volume, then you need to issue   
"mt bsf 2"

The logic behind this is as follows:
"MTBSF count" backspaces over count file marks, stops, and then  
positions on the <tt/EOT/ side of the last skipped file mark. This means,  
an "mt bsf 2" will position right at the beginning of the previous  
volume. 

&lt;answer form Claus Heine&gt;

<sect1>By non-rewinding, they mean that it doesn't automatically rewind, correct? It doesn't mean that under no circumstances it will rewind, right?  I tried using /dev/zqft0, and it instantly rewinds the tape.<P>

You are right: auto-rewind means, the tape is rewound when the tape  
device is closed, non-rewinding  means, the tape isn't automatically  
rewound when the tape device is closed (but you can, of course, use  
the tape motion commands BSF/FSF etc. to position the tape head at  
every position you like).

&lt;answer form Claus Heine&gt;

<sect1>What is the difference between what mt considers a record and what it considers a file?<p>

A record is the minimal amount of bytes that will be accepted by the
tape in one read/write operation (except in "variable block size mode"
where it just should be the amount of data actually written in a
single write operation??). 

For <em/zftape/ every read and write access has to be a multiple of a fixed
block size (fixed, but tunable with <tt/MTSETBLK/). This block size is a
"tape record" (as mentioned in the GNU mt man page and defaults to
10kb for <em/zftape/.

A "file" (in the sense of the mt man page) is a, well, misleading
terminus. What is meant is an area of the tape between two file
marks. This is not a file like a file on the file system, in the sense
that it could have a name, file access modes, could be moved or copied
with cp, mv, rm etc. 

Instead, It simply is the area of the tape that was recorded in one
backup session, its end is marked by a tape file mark, and its
beginning is delimited by either <tt/BOT/ or the file mark of the previous
tape "file". That tape "files" are the things that can be skipped with
the <tt>MTBSF/FSF</tt> commands.

&lt;answer form Claus Heine&gt;

<sect1>Reusing tapes with zftape without reformatting the tape.<p>

We try to answer the followong questions :
<itemize>
<item>
Is there a good way to erase, as in remove the data or at least the volumes 
from a tape, without reformating?  
<item>
Can you overwrite the last volume on a tape with making a mess out of it? 
<item>
Can you overwrite the last several volumes without making a mess? 
<item>
Can you delete the last volume?
</itemize>

If you want to "erase" an entire cartridge, then simply do:

<tscreen><verb>
mt -f /dev/qft0 erase
</verb></tscreen>

This will erase the volume table (i.e. the "file marks").

Pre-ftape-3.x releases of zftape and ftape used to allow overwriting
of already existing volumes on a cartridge. I have removed this
feature as it was reported that it already has caused data-loss with
some backup programs.

If you indeed need to remove some volumes on the tape then you should
use the 

<tscreen><verb>
vtblc
</verb></tscreen>

program that comes with the <tt/ftape-tools/ package which can be
down-loaded from the same locations as the <tt/ftape/ kernel driver
package. Please refer to the documentation which is contained in the
<tt/ftape-tools/ package for more information.

If you simply want to reuse old tapes, then it suffices to do

<tscreen><verb>
mt rewind
</verb></tscreen>

If the tape is at BOT (Begin Of Tape) then every write access to the
tape will silently erase all file marks and overwrite the data already
existing on the tape.

&lt;answer by Claus Heine&gt;

<sect1>This script implements a simple contents listing for the zftape package using the "MTIOCVOLINFO" ioctl.<p>

Here is as little perl/bash script that lists the contents of a cartridge
using the <em/zftape/ specific "volinfo" ioctl. Hope this shows how to
handle this kind of stuff.
 
What it basically does is the following:

<enum>
<item>
Rewind the cartridge
<item>
Issue the volinfo command:
<tscreen><verb>
   claus@thales:~&dollar; mt volinfo
   file number          = 1
   block size           = 10240
   physical space used  =  522.0 kilobytes
   real size of volume  =  520.0 kilobytes
</verb></tscreen>
Parse the ouput and place the values in appropriate variables
<item>
Skip to the next volume with "mt fsf"
<item>
Exit if this gives an error (EOD), otherwise "goto 2)"
</enum>

<bf/The Perl Script/

<tscreen>
<verb>

#!/usr/bin/perl
#
#     Copyright (C) 1997 Claus-Justus Heine
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program 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.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#   This script implements a simple contents listing for the zftape
#   package using the MTIOCVOLINFO ioctl.
#

$version = <<EOT;
listtape-1.0 -- a perl script to list the contents of a floppy tape cartridge
under Linux using the zftape driver

RCS \$Revision$
RCS \$Date$
EOT

$tapedev = "/dev/tape";
$usage = <<EOT;
Usage: listtape [options ...]

Mandatory or optional arguments to long options are mandatory or optional
for short options too.

-f, --file=FILE       Tape device to use. Default is  "/dev/tape".
-h, --help            Print this help.
-?                    Same as '-h'.
--usage           Same as '-h'.
-V, --version         Print version information.

Author: Claus-Justus Heine <claus\@momo.math.rwth-aachen.de>
EOT

while ($ARGV[0] =~ /^-/) &lcub;
$_ = shift; 
if (/--file/) &lcub;$_ = shift; $tapedev = $_; next;&rcub; 
if (/-f/) &lcub;$_ = shift; $tapedev = $_; next;&rcub; 
if (/--help/) &lcub; print $usage; exit 0; &rcub;
if (/-h/) &lcub; print $usage; exit 0; &rcub;
if (/--usage/) &lcub; print $usage; exit 0; &rcub;
if (/-\?/) &lcub; print $usage; exit 0; &rcub;
if (/--version/) &lcub; print $version; exit 0; &rcub;
if (/-V/) &lcub; print $version; exit 0; &rcub;
die $usage;
&rcub;

&amp;open_tape($tapedev, "status");
while(<FTMT>)
&lcub;
$online = 1 if (/.*online.*/);
&rcub;

if (! $online) &lcub; die "No cartridge present.\n"; &rcub;

&amp;mtop($tapedev, "rewind");

printf "%11s%12s%20s%20s\n",
"file number", "block size", "volume size", "tape space";

while (1)
&lcub;
&amp;open_tape($tapedev, "volinfo");
while (<FTMT>) &lcub;
if (/^file number\s*=\s*([0-9]*)$/) &lcub; $filenumber = $1; &rcub;
if (/^block size\s*=\s*([0-9]*)$/) &lcub; $blocksize = $1; &rcub;
if (/^physical space used\s*=\s*([[0-9]*.*)/) &lcub; $rawsize = $1; &rcub;
if (/^real size of volume\s*=\s*([[0-9]*.*)/) &lcub; $size = $1; &rcub;
&rcub;
close(FTMT);
if (&amp;mtop($tapedev, "fsf 1") != 0) &lcub;
&amp;mtop($tapedev,"rewind");
print "\nRemaining space: $rawsize\n";
print "Tape block size: $blocksize\n";
exit 0;
&rcub;	    
printf "%6d          %5d  %20s%20s\n",
    $filenumber, $blocksize, $size, $rawsize;
&rcub;

sub mtop
&lcub;
local ($tape, $operation) = @_;
local ($exitval);
system "ftmt -f $tape $operation > /dev/null 2>&amp;1";
&rcub;

sub open_tape
&lcub;
local ($tape, $operation) = @_;
local ($command);

$command = "ftmt -f " . $tape . " " . $operation . " |";
open(FTMT, $command) || die "Couldn't open $command -- $!\n";
&rcub;

</verb></tscreen>



<bf/The Bash Script/

<code>

#! /bin/bash
#
#     Copyright (C) 1997 Claus-Justus Heine
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program 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.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#   This script implements a simple contents listing for the zftape
#   package using the MTIOCVOLINFO ioctl.
#

#
# insert better option parsing here
#
TAPEDEV=$&lcub;1-/dev/tape&rcub;

if ! echo $TAPEDEV | grep "/dev/n"
then
TAPEDEV=/dev/n$(basename $TAPEDEV)
fi

if ! [ -c $TAPEDEV ]
then
echo $TAPEDEV is not a character device!  1>&amp;2
exit 1
fi

if ! mt -f $TAPEDEV rewind
then
echo Could not rewind $TAPEDEV - no cartridge present?  1>&amp;2
exit 1
fi

echo -e "\nContents of $TAPEDEV:\n"

printf "%11s%12s%20s%20s\n" "file number" "block size" "volume size" "tape space"

trap "rm -f /tmp/$0.$$" exit

while true
do
if ! foo=$(mt -f $TAPEDEV volinfo |cut -f 2 -d =)
then
echo $TAPEDEV doesn\'t seem to be a floppy tape device 1>&amp;2
exit 1
fi
#
# "echo foo | read foo" will not work as the "read foo" is executed in
# another shell.
#
echo $foo > /tmp/$0.$$
read file blksz used usedunit size sizeunit < /tmp/$0.$$
if ! mt -f $TAPEDEV fsf 1 > /dev/null 2>&amp;1
then
echo -e "\nRemaining space: $used $usedunit"
echo -e "Tape block size: $blksz"
if ! mt -f $TAPEDEV rewind
then
    echo Rewind of $TAPEDEV failed 1>&amp;2
    exit 1
fi
exit 0
fi
printf "%6d          %5d  %20s%20s\n"\
$file $blksz "$size $sizeunit" "$used $usedunit"
done

</code>

&lt;answer from Claus Heine&gt;

<sect>FAQ: "Tape and Drivers" related questions !<p>

<sect1>What are good makers of Travan tapes?<p>

I was the UNIX Product Manager at Archive Corp (Prior to the Conner/Seagate   
mess) and we performed extensive tests of tape media for compatibility   
certification, including retentivity, flaking and length consistancy.  Based   
on the results of the tests, we selected the best of these certified   
manufacturers' products to private label as our own media.  Here is the   
order in which we selected vendors up through 1995 (when I lost contact   
with the ATI group):

<descrip>
<tag/QIC/
	<enum>
		<item> 3M (now known as Imation)
            	<item> QMaxell/Sony (tie)
           	<item> (BTW - Iomega uses Sony private-labelled media)
	</enum>
<tag/4MM/
	<enum>
		<item> Fuji
        	<item> Maxell/Sony (tie - is this a trend?)
	</enum>
<tag/8MM/
	<enum>
		<item> Fuji/Exabyte - which we believed to be OEM'd Fuji (tie - so much for trend!)
		<item> Sony
         	<item> Maxell
	</enum>
<tag/DLT/
	<enum>
		<item> Maxell
        	<item> Sony
	</enum>
</descrip>

Otherwise, we had entries in our search from other vendors which were   
generally a private-labelled version of one of the major labels above. The   
exceptions were Verbatim and DIC.  Both of these manufacturer's media had   
fall-out rates and length discrepancies that were so high that we would not   
certify them and even warned customers about them indicating that we could   
not offer any sort of guarantee that they would get a good backup using the   
media from these manufacturers.

In addition, since coming to EST, I've found that Verbatim media is still   
not worth the money saved in purchasing it.  We have 11 of their TR-Extra   
and QIC-Extra (QICXL) tapes that were useless after fewer than 20 passes each.

While this is my personal opinion, it is based on over 9 years of experience   
with this very question, I strongly recommend Imation/3M media for QIC/Travan   
user, Fuji media 4MM users, Exabyte/Fuji for 8MM and DEC labelled media   
for DLT users.

&lt;answer from Tim Jones&gt;

<sect1>Where can I obtain the QIC standards?<p>

If you wish to help developing <em/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:  

<tscreen><verb>
Quarter Inch Cartridge Drive Standards, Inc.
311 East Carrillo Street
Santa Barbara, California 93101
Phone: (805) 963-3853
Fax:   (805) 962-1541
</verb></tscreen>

Note: They are registered as `Freeman Associates, Inc' in the phone  
book.

&lt;from the Ftape-Howto&gt;

<sect1>Is the Iomega Ditto 2GB drive supported?<p>

Yes, if you are using version <tt/ftape-3.x/ or later of the <em/Ftape
drivers/ from the <htmlurl
url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="Ftape Home Page"> or from
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes"
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">.

&lt;answer from Tim Jones&gt;

As the Ditto 2GB is a Tr-3 tape (though it can only store 1GB instead of the  
1.6GB you get with a regular Tr-3 drive) you need an FDC (FDC means: Floppy  
Disk Controller) that is capable of at 1Mbit/sec transfer rate. You don't need  
to worry about this if you have an accellerator card (i.e. the Ditto Dash  
controller). Otherwise try to purchase an FDC that claims to be capable of  
driving 2.88Mb floppies because this implies that the FDC is capable of 1Mbit  
transfer rate.

<em/Ftape/ prints the maximum data rate of the FDC to the kernel log
files like this:
<verb>
ftape-ctl.c (ftape_init_drive) - Highest FDC supported data rate: 500 Kbps.
</verb>

&lt;answer from Claus Heine&gt;

<sect1>Is the Iomega Ditto Max drive supported?<p>

Yes, if you are using version <tt/ftape-4.02/ or later of the
<em/Ftape drivers/ from the <htmlurl
url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
name="Ftape Home Page"> or from <htmlurl
url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes"
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">.

&lt;answer from Claus Heine&gt;

<sect1>Is the Iomega Ditto Max Pro drive supported?<p>

Yes. But if you want to use the 5GB (10GB with compression) cartridges
you don't need it. With <tt/ftape/ there doesn't seem to be any
difference between the <tt/Ditto Max/ and the <tt/Ditto Max Pro/.

&lt;answer from Claus Heine&gt;

<sect>FAQ: Miscellaneous !<p>

<sect1>How to subscribe to the Ftape Mailing List?<p>

You can subscribe to that list by sending mail to
<tscreen><verb>
majordomo@vger.rutgers.edu
</verb></tscreen>
with the single line
<tscreen><verb>
subscribe linux-tape
</verb></tscreen>
in its body. Please store the answer you get from majordomo in a safe place   
because it contains instructions how to <tt/UNSUBSCRIBE/ from the mailing list.

&lt;answer from Claus Heine&gt;

<sect1>How to un-subscribe from the Ftape Mailing List?<p>

Send mail to
<tscreen><verb>
majordomo@vger.rutgers.edu
</verb></tscreen>
with the single line
<tscreen><verb>
unsubscribe linux-tape MY@EMAIL.ADDRESS
</verb></tscreen>
where <tt/MY@EMAIL.ADDRESS/ has to be replaced by the email   
address that you used when subscribing to the list. Note that you must   
have received an email with instructions how to unsubscribe from the   
mailing list at the time you subscribed to it.

&lt;answer from Claus Heine&gt;

<sect1>Links to related information.<p>


<htmlurl url="http://www.uwsg.indiana.edu/usail/library/backups.html"
 name="&lt;http://www.uwsg.indiana.edu/usai/library/backups.html&gt;">

More links wanted !!!

<!-- ****** Ftape-FAQ END, wordly included. Keep in sync with the separate
FAQ distribution ****** -->

<!-- ****** Debugging the ftape driver ****** -->


<sect>Debugging the <tt/ftape/ driver<p>


<sect1>The kernel/<tt/ftape/ crashes on me when I do `...' - is that a bug?<p>

No, that is a feature <tt/&semi;&hyphen;&rpar/

Seriously, reliable software do not crash.  Especially kernels do not
or rather <bf>should</bf> not crash.  If the kernel crashes upon you
when you are running <tt/ftape/, and you can show that it is
<tt/ftape/ that is messing things up, regard it as a Bug That Should
Be Fixed.  Mail the details to the maintainer
(<tt/&lt;heine@math1.rwth-aachen.de&gt/) and to the tape list.


<sect1>OK, it's a bug ...ehhh... feature - How do I submit a report?<p>

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
<tt>:-/</tt> This is a quick check list:

<itemize>
<item> Kernel version, and patches applied
<item> <tt/ftape/ version
<item> tape drive model / manufacturer
<item> Expansion bus type (EISA, ISA, PCI, or VL-bus)
<item> What you did to expose the problem
<item> What went wrong on your system.
<item> Do not delete the kernel and the <tt/ftape.o/ file. I might want
	you run try some patches out or run a different test on your system.

</itemize>

Increase the tracing level to 4 or 5 and run the command that caused
problems again (don't do it if your fear that you loose data or damage
your hardware, there is absolutely no warranty for neither data loss
nor hardware damage caused by <tt/ftape/, remember this). Increasing
the trace level beyond 5 probably doesn't make any sense as it affects
the timing of the driver in a way that it doesn't work well any
more. Get the tracing data from the kernel log or <tt>/proc/kmsg</tt>,
depending on where you harvest your error messages.  Try to look at
what <tt/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
<tt/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
<tt/ftape/ would not run in a PCI based box, but ran flawlessly in a
normal ISA based 386DX machine (see section <ref id="pci-boxes"
name="Getting PCI motherboards to work with <tt/ftape/"> on PCI
machines above)

Also, please think of the poor souls who actually <em>pay</em> the
their Internet access (like me): avoid posting a (huge) log from the
<tt/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 <tt/&lt;linux-tape@vger.rutgers.edu&gt;/. You
might also want to mail the bug to
<tt/&lt;heine@math1.rwth-aachen.de&gt;/.


<sect>Contributions<p>

The following is a list of notable folks that have contributed to
<tt/ftape/'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. You can view anoterh attempt to collect
such kind of information at
<htmlurl
url="http://samuel.math.rwth-aachen.de/~LBFM/claus/ftape/halloffame.html"
name="Ftape's Hall of Fame">

<tt/Johan De Wit/ &lt;jo@correct.nl&gt: The maintainer of the Ftape
FAQ.

<tt/Kevin Johnson/ &lt;kjj@pobox.com&gt: The previous maintainer of
the <tt/Ftape-HOWTO/

<tt/Kai Harrekilde-Petersen/ &lt;khp@dolphinics.no&gt: The
previous maintainer of <tt/ftape/ and the HOWTO.<p>

<tt/Andrew Martin/ &lt;martin@biochemistry.ucl.ac.uk&gt: Many
additions to the HOWTO.<p>

<tt/Bas Laarhoven/ &lt;bas@vimec.nl&gt: The original author of
<tt>ftape</tt>.<p>

</article>
<!--  LocalWords:  Ftape HOWTO Justus heine rwth aachen do's dont's QIC DAT unc
 -->
<!--  LocalWords:  Linux HOWTOs HOWTO's sunsite edu ftape Kai Harrekilde khp CD
 -->
<!--  LocalWords:  dolphinics kjj pobox SGML URLs Martin's GPL Connor TST Mbps
 -->
<!--  LocalWords:  fdc linux vger rutgers SoundBlaster dev qft vimec nl usr src
 -->
<!--  LocalWords:  txt kinda QICstream Tallgrass FileSecure Escom Powerstream
 -->
<!--  LocalWords:  CP dennisf denix Travan TR kosowsky bellini harvard millner
 -->
<!--  LocalWords:  bevc blacksburg va compuserve zftape chris cs wmich kjh usc
 -->
<!--  LocalWords:  pollux CTC MB merkel def gmpt gmeds IRQ yakkocs dknet dk
 -->
<!--  LocalWords:  jzc primenet amc uva CTT Iomega jmorris dtx ttait SOMEFILE
 -->
<!--  LocalWords:  pschmidt tiac erwin Ammerlaan dutiwy twi tudelft klein colin
 -->
<!--  LocalWords:  informatik colina co uk FS Antti Virjo klanvi uta fi scsi FC
 -->
<!--  LocalWords:  sbailey xcc mc xerox eg Trakker Accutrak COREtape PSU PCI cd
 -->
<!--  LocalWords:  czf xzf xf df mt nqft fsf eof EOD unmounting filesystem ct
 -->
<!--  LocalWords:  ndering grahamc org au Chapman's init inittab getty rc sh fd
 -->
<!--  LocalWords:  fstab minix hda mnt av RAMDISK jdewit unicall Linuxdoc claus
 -->
<!--  LocalWords:  http www LBFM LDP XYZ SMP depmod modprobe insmod ftmt EZ PnP
 -->
<!--  LocalWords:  modversions reconfig DMODVERSIONS sftape uname GB jo Jochen
 -->
<!--  LocalWords:  Exabyte var ECC SVGA dmaalloc syslog swapout Syslogd sbin ok
 -->
<!--  LocalWords:  fsr shoeshining cais Adaptec zqft reten afio xdev bru EOT dd
 -->
<!--  LocalWords:  setdrvbuffer QICWide ftformat bsf setblk lsmod cvvzf gzip ai
 -->
<!--  LocalWords:  execlp childs cpio mit gz fileutils nftape eom rft Hoenicke
 -->
<!--  LocalWords:  cp harddisk xvf cvf MTBSF iwill usedunit sizeunit tjones
 -->
<!--  LocalWords:  MTIOCVOLINFO perl volinfo bf listtape tapedev ARGV rm estinc
 -->
<!--  LocalWords:  mtop printf filenumber blocksize rawsize nRemaining exitval
 -->
<!--  LocalWords:  basename tmp foo blksz ATI colorado
 -->
<!--  LocalWords:  Imation QMaxell Maxell OEM'd DIC QICXL DLT Tr Mb
 -->
<!--  LocalWords:  Carrillo Mbit accellerator ctl Kbps ehhh EISA ISA VL kmsg ac
 -->
<!--  LocalWords:  ucl
 -->
