ftape floppy tape driver under Linux. It focusses on
the newest version which is ftape-4.02 at the time
of this writing. This HOWTO is to be intended as first step help
and source of information. The 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
(FDC) which may be either an internal FDC or inside of
certain parallel port floppy tape drives. Please refer to the
section Supported drives for further
information. ftape does not 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
the
Linux HOWTO index, while the real HOWTO's can be fetched
(using ftp) from
sunsite.unc.edu:pub/Linux/doc/HOWTO (this is the
``official'' place) or via the World Wide Web from
the Linux Documentation
Project home page.
ftape
ftape
ftape-2.x, ftape-3.x and
ftape-4.x versions
ftape driver
ftape and
floppies
ftape
ftape
ftape
ftape driver
ftape
crashes on me when I do `...' - is that a bug?
The Linux ftape-HOWTO may be reproduced and distributed in whole or in part, subject to the following conditions:
Copyright (c) 1993-1996 by Kai Harrekilde-Petersen Email: khp@dolphinics.no Copyright (c) 1996-1997 by Kevin Johnson Email: kjj@pobox.com Copyright (c) 1998 by Claus-Justus Heine Email: heine@math1.rwth-aachen.de
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
ftape is now a part of the kernel
distribution.ftape
ftape-3.x came with a manual of its own,
which is contained in the ftape-3.04d package
available from the usual places. See
Getting Ftape.
ftape-4.x also has a documentation package
ftape-doc which is available from the usual
places. This Ftape-HOWTO, however, also focusses on
ftape-4.x and is meant as an entry point to the
available documentation. See Getting
Ftape.
The ftape-tools package (including useful
utilities for ftape) comes with its own manual.
See Getting Ftape.
The Ftape-FAQ is included wordly in this
manual, but more recent versions may be found at
http://www.correct.nl/~ftape.
The maintainer of the source for ftape is Claus
Heine
<heine@math1.rwth-aachen.de>.
He has a web page at
http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/.
If you have a problem or questions about ftape, try posting to
the Linux Tape mailing list
linux-tape@vger.rutger.edu (see
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 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 Supported
drives and Unsupported drives
for a list of supported and unsupported drives.
You should try to post a summary of your problems and its solution(s), after you've got it working, even if you only got it partially working. Please also send a copy copy of your solution to the Linux Tape mailing list at <linux-tape@vger.rutgers.edu> 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 the Linux Documentation home page or ftp to ftp://sunsite.unc.edu:/pub/Linux/doc/HOWTO to see if there exists a more recent version. This could potentially save you a lot of trouble.
If you email me, please include the string ftape
in the subject line. This will help ensure the mail doesn't
inadvertently get buried. But preferrably you should email to the
Linux Tape mailing list at
<linux-tape@vger.rutgers.edu>
instead of contacting me directly.
ftape
ftape is a driver program that controls various
low-cost tape drives that connect to the floppy controller.
ftape is not a backup program as such; it is a
device driver, which allows you to use the tape drive (just like
the SoundBlaster 16 driver let you use your sound card) through
the device files /dev/[n]qft[0-3].
ftape was originally written by Bas Laarhoven
<bas@vimec.nl>, with ``a little help from his
friends'' to sort out the ECC (Error Correcting Code) stuff.
ftape is copyrighted by Bas under the GNU General
Public License, which basically says: ``go ahead and share this
with the world, just don't disallow other people from copying it
further''.
ftape has undergone several changes since then.
While the Linux-2.0.x kernel series still contains
ftape-2.08 the v2.1.x and soon the v2.2.* kernel
series come with ftape-3.x (hopefully even with
ftape-4.02, but this wasn't clear at the time of
this writing) which differs in some points from the
ftape-2.x driver. Since version 3.00
the 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.
ftape is quite stable, and has been that for some
time now. It is reliable enough for critical backups (but it's
always a good idea to check your backups, so you won't get a
nasty surprise some day).
ftape supports drives that conform to the QIC-117
and one of the QIC-80, QIC-40, QIC-3010, and QIC-3020 standards
as well as the Iomega Ditto 2GB and Ditto Max drives which no
longer strictly conform to the QIC standards in all respects.
ftape can drive floppy tape drives that connect
to the internal FDC as well as certain parallel port floppy tape
drives.
ftape supports neither QIC-02, IDE (ATAPI), nor
SCSI tape drives. SCSI drives are accessed as
/dev/[n]st[0-7] and are supported by the kernel
through the SCSI drivers. If you look for help on SCSI tape
drives, you should read the SCSI-howto. ATAPI tape
drives are supported by the kernel since 1.3.46. See section
Supported drives and
Unsupported drives for a list of
supported and unsupported drives.
ftape
ftape
The v2.0.x versions of the kernel include version 2.08 of
ftape I recommend, however, that you grab the latest
version of the full source code package for ftape.
It is a newer version, includes files that are not included in
the kernel v2.0.X distribution, and includes much better
documentation about how to install ftape. The v2.1.x
and later versions of the kernel include the version 3.04 of
ftape.
I recommend that you download the latest stable version of
ftape which is 4.02 at the time of this writing and
is available from
http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/archives.html
as well as from
ftp://sunsite.unc.edu/pub/Linux/kernel/tapes/.
You probably should also grab the ftape-doc and
the ftape-tools package that are available from the
same locations.
If you still want to use the 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 Supported
drives gives detailed information about which version of the
ftape driver supports which hardware.
ftape-2.x, ftape-3.x and
ftape-4.x versions
ftape-3.x and ftape-4.x use the file
system interface that was implemented for a branch release which
was called zftape. Actually, the module that
implements the VFS (Virtual File System)
interface of ftape-3.x and ftape-4.x
still is called zftape.o and its
C-sources inside the kernel tree reside in
[/usr/src/linux/]drivers/char/ftape/zftape/.
ftape-2.x (i.e. the version still contained in
the v2.0.x kernel) uses another file system interface, that was
implemented by ftape's original author Bas
Larhoven.
The conceptional difference between ftape-2.x
and later versions of ftape is the way file
marks are implemented.
Floppy tape devices don't have real file marks.
File marks are used to distinguish different backup sets if you write multiple backup sets to a tape. SCSI and QIC-150 tapes have real 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
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. mt) the developers of
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.
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 QIC standards already designate
a special region to store such information in, the so called
volume table segment. Since ftape-3.x
this 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 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 ftape under
DOS, safe you write your own software to do that.
There are certain differences in the IOCTL
This IO control interface is used by e.g.
mt to rewind the tape or skip to the next file
mark or do any other tape operation.
interface between ftape-2.x and
ftape-3.x and later. A detailed description can
be found in the ftape-manual contained in the
ftape-doc package. See
Getting Ftape.
Formatting of cartridges is supported with
ftape-3.x and later only. Please get the
ftape-tools package that contains the
ftformat program that interfaces to the driver
to format cartridges. See Getting
Ftape. The ftape-tools package comes with
(more or less) detailed documentation, so the case of
formatting cartridges is not dealt with in this document.
ftape-3.x supported user transparent
on-the-fly compression in software. This feature (or
bug) has vanished in ftape-4.x as it
made further improvements concerning the realiability of
backups very very hard. This means, ftape-4.x
comes without compression support.
However de-compression of compressed archives
produced with ftape-3.x 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 taper which calls
the MTIOC ioctls itself instead of relying on
the mt program to perform tape operations.
The ftape-manual contained in the
ftape-doc package contains much more detailed
information about ftape`s file system interface as
well as implementation notes which by far exceed the scope of
this HOWTO. See Getting Ftape for
informations about where to obtain the manual.
The following section provides some useful information to get you going with the installation of v4.x which is not shipped with the kernel source tree yet but has to be downloaded separately, see the section Getting ftape above.
Once you've downloaded the source code (probably
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 /usr/src/ or ~/src.
When the tar file is extracted, it will dump everything into a
ftape-4.02 subdirectory, so that you'll end up, in
the example I've given, with something like
/usr/src/ftape-4.02 or
~/src/ftape-4.02.
NOTE: you cannot compile ftape-4.02 into
your v2.0.x kernel. Instead, configure your kernel to not
compile the ftape driver and follow the installation
instructions in the ftape-4.02 distribution and
install ftape-4.02 as a module.
Read the README file. The README is
required reading. It's the top of the tree, so to speak. If there
are specific files that the README tells you to read
then read them. It will make the process much less
complicated.
Do NOT proceed with compiling the package until you have read
the appropriate README files and the
INSTALL file.
Afterwards you need to edit the MCONFIG file and
configure you package according to your hardware. The
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 MCONFIG simply give the
default configuration, but you don't need to recompile the driver
to change IO addresses or interrupt settings. The file
INSTALL and the file 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.
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
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
ftape-4.x so you don't need to download the
ftape-4.x kernel driver package.
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 make menuconfig or
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
[/usr/src/linux/]Documentation/ftape.txt
of the Linux-v2.1.x and later kernel distributions.
ftape driver
If you want to follow the development of the
ftape driver, you should subscribe to the Linux Tape
mailing list linux-tape@vger.rutgers.edu. To do so
you need to send an email saying `subscribe
linux-tape' (in the body) to
majordomo@vger.rutgers.edu. When you subscribe, you
will be sent a greeting mail, which will tell you how to submit
real mails and how to get off the list again. Store this email
in a safe place. Please.
Please note that I do not, repeat DO NOT, have any special powers with regard to this mailing list. If you're stuck on the list, don't bother to tell me that. I can only shrug and send you my sympathy (but that won't get you off the list).
ftape and
floppies
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
floppy and the ftape driver do not talk
to each other. Thus, if you have mounted a floppy and then try to
access the tape drive, ftape will complain that it
cannot grab IRQ6 and then die. This is especially a problem when
designing a emergency disk for use with ftape. This solution is
to either load the boot/root disk into a ramdisk and then unmount
the floppy, or have two floppy drive controllers.
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 :-).
Yes, you can, if you use ftape-3.04d or above. To
format a floppy tape cartridge you need a user level tool called
ftformat as well which is contained in the
ftape-tools distribution (see section
Getting ftape).
The ftape-tools package comes with its own
manual, so I do not need to repeat here how to use
ftformat.
The following are known to work:
tape.exe)qs3.exe -- QICstream
v3?)These programs are known to be more or less buggy:
As a general rule, most software under DOS should work. The
Conner Backup Basics v1.0 has a parameter off by one (someone
could not read the QIC-80 specs right!), which is corrected in
version 1.1. However, ftape detects this, and will
work around it. Dennis T. Flaherty
(<dennisf@denix.elk.miles.com>) report that
Conner C250MQ owners can obtain the new v1.1, by calling Conner
at 1-800-4Conner (in the US) and ask for an upgrade (for a
nominal fee for the floppy). The Windows versions should work
fine. Some versions of Colorado's tape program for windows, has
an off-by-one error in the number of segments. ftape
also detect and work around that bug.
Central Point Backup can be used, but it wastes precious tape space when it encounters a bad spot on the tape.
NOTE: If you are running a formatting software under DOS, which is not mentioned here, please mail the relevant info to me ( <heine@math1.rwth-aachen.de>), so I can update the list.
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.
The coating on the tape is an oxide compound. As the tape is dragged across the tape head it has a tendency to leave tiny amounts of residue on the head. You should periodically use a tape cleaner - following the specs for the drive in question. Tape cleaners should be available from any distributer of tapes.
One more additional note about tape cleaning. You might want to clean the drive after the first use of a brand new tape. A brand new tape will typically leave quite a bit of residue the first time it's used.
Thanks to Neal Friedman for the explanation and suggestion that this information be included in the HOWTO.
In rare occasions it can happen that the tape drive doesn't detect the 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
http://www.iomega.com/support/techs/ditto/3006.html
and at the Hewlett Packard WWW pages at
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.
All drives that are both QIC-117 compatible and one of the QIC-40, 80, 3010, and 3020 standards should work. QIC-WIDE and Travan drives are also supported (TR-1 is just QIC-80 with 8mm tapes, while TR-2 and TR-3 is a.k.a QIC-3010 and 3020 respectively). 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 (<heine@math1.rwth-aachen.de>) like this:
This is a comment.
Currently, the list of drives that are known to work with
ftape is:
<kosowsky@bellini.harvard.edu> reported a problem doing a 1G backup using taper.
Support added by Jochen Hoenicke <Jochen.Hoenicke@Informatik.Uni-Oldenburg.DE>.
The problem reports are probably totally out-dated. In particular, thezftapethe people talk about doesn't exist any more, and theftapedriver is the veryftape-2.08.
Works with 3M Travan 400M (TR-1) tapes with 120M tapes. Also reported that mt dies, but with backups using tar it works ok. With cpio, ftape is recommended rather than zftape. (<millner@millner.bevc.blacksburg.va.us>)
Problems have been reported with the drive continually stopping and starting with zftape (<75104.1756@compuserve.com>). This appears to be a problem with the tape going too fast for the computer; the DMA buffers are getting flushed 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 (<millner@millner.bevc.blacksburg.va.us>).
The 250Q is reported to generate write error and frequent repositioning. (Frank Stuess at Nacamar Data Communications)
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.
The 400 and 800 models only work with TR-1 tapes.
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.
Works with TR-3 tapes at 1Mbps (ie. 1600M capacity only). Wirks with QIC-WIDE 400M tapes (Sony 5122's?) (<chris@cs.wmich.edu>). Works with TR3, QIC-3010, and QIC-3020 tapes. Comes with a 2MB FDC which the Promise 2300+ 1Mbps controller works (<kjh@pollux.usc.edu>).
Reported that the floppy disk can no longer read low-density floppies. May have to fiddle with IRQ/ports/dma channels (<chris@yakkocs.wmich.edu>).
The TST3200R works well with ftape.
The TST800R works with TR-1, Sony QW5122F (210M) and DC2120 tapes.
Works well withftapesinceftape-2.07at least. Used it myself until the drive died with a melted transistor. Probably caused by over-heating it previously.
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. (<jmorris@dtx.net>)
Works with QIC-WIDE tapes (<pschmidt@slip.net>). Partially works with QIS-3200. Using the HSC-2 controller, the DMA channel needs to be changed (incremented by 1, channel2?, Modify the Makefile). You then need to modify the ftape Makefile to reflect this change. However, ftape seems to be a bit flaky with this (no version number supplied) (<ttait@tiac.net>). It may not work at 2Mbps (QIC-3020) with the HSC controller. The tape died with a messages like "dumb tape stop" and has since been unreliable (<ttait@tiac.net>).
No recent informations available
Work with QIC-3010 tapes.
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 <kjj@pobox.com>).
Refer to the fileMCONFIGof recentftapedistributions for other suggestions for ioport, irq and DMA channel.
May require the having {0x08882, 80,
wake_up_colorado, "Iomega 3200"}, added to
vendors.h on older versions of
ftape.
Problems reported with ftape 2.07 and kernel 1.12.13. With all sorts of combinations of accelerator, etc, the drive may (on some systems) only be accessed once (<erwin@box.nl>). Also, after the first access, the next use of the tape says it is write protected (<erwin@box.nl>, <M.J.Ammerlaan@dutiwy.twi.tudelft.nl>).
There has been one report of a problem where the tape got wound off the end of the spool.
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.
Should have been fixed somewhere betweenftape-3.00andftape-4.00. Unluckily, the fast-skipping facilities of all Iomega floppy tape drives are really poor. Recentftapeversions work around this problem. I suggest getting the latest version of theftapedriver when you experience this problem.
Works with Travan TR1, TR2, or DC2120 tapes (<klein@informatik.uni-rostock.de>).
Support added by Jochen Hoenicke
<Jochen.Hoenicke@Informatik.Uni-Oldenburg.DE> to
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 ftape).
Supported since ftape-4.00. Thanks to Tim
Jones <tjones@estinc.com>.
Can't format cartridges, writing is only possible with
special Ditto Max cartridges (hardware limitation, not a
lacking feature of ftape)
I wasn't able to get the Ditto Max to work with any other
device than /dev/[n]qft0. 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.
Ditto Max
Pro to use the 5/10GB cartridges. With
ftape there is no real difference between the
Ditto Max and the Ditto Max Pro.
Supported since ftape-4.00 with the
bpck-fdc FDC driver.
Reported not to work with kernel 1.3.79 and ftape (no version given) or with kernel 1.2.13 and zftape 1.04 (<colin@colina.demon.co.uk>).
The mentionedftapedriver versions are out of date. If you still have such a beast try the more recent versions of theftapedriver.
If you have a Tallgrass FS300 and an AHA1542B, you need to
increase the bus-on / bus-off time of the 1542B. Antti Virjo
(<klanvi@uta.fi>), says that changing
CMD_BUSON_TIME to 4 and
CMD_BUSOFF_CMD to 12 in
linux/drivers/scsi/aha1542.c will do the
trick.
You can always check out the newest list of drives that are
recognised by ftape, by looking in the file
vendors.h in the ftape
distribution.
Although I do not want to endorse one drive type over another, it has been reported that the Colorado DJ-20 drive is rather noisy, when compared to, say, a Conner C250MQ drive ('tis said that the Colorado is 5-10 times as noisy as the Conner drive. Since I have neither, I can't tell for sure).
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
(<heine@math1.rwth-aachen.de>).
These dedicated high-speed tape controllers are supported by
ftape:
Support for the FC-10 controller has been merged into the
ftape driver in version 1.12. See the
RELEASE-NOTES and the Makefile files in
the ftape distribution. Since of version 2.03 of
ftape, the FC-20 controller will work, but only at
1Mbit/sec (check the Release notes!).
The support for the MACH-2 controller was added in
ftape-1.14d.
To use the Iomega Tape Accelerator II (not to be
mistaken as the Iomega Ditto Dash!), use -DMACH2,
and set the right settings for I/O base, IRQ and DMA. This works
(by the empirical testing of Scott Bailey
<sbailey@xcc.mc.xerox.com>),
with at least ftape-2.02.
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 ftape-3.00.
This controller requires the use of e.g. the
isapnptools package to configure it. You may get it
from
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 <tjones@estinc.com> nor I <heine@math1.rwth-aachen.de> 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 ftape.
The Irwin AX250L (and the IBM Internal Tape Backup Unit) does
not work the ftape. This is because they only
support QIC-117, but not the QIC-80 standard (they use Irwin's
proprietary ``servoe (Rhomat)'' format). I know nothing about the
Rhomat format, nor where to get any info on it. Sorry.
The COREtape light does not accept the initialisation commands, we're feeding it. This pretty much leaves the drive unusable.
ftape
If you have a floppy controller which has a female DB37
connector on the bracket (and some means of delivering power to
the drive), you can use it with ftape. OK, that
sentence was not very obvious. Let's try it this way: Some FDC's
(the very ancient one's), have a DB37 connector on the bracket,
for connecting to external floppy drives.
If you make a suitable cable from the DB37 connector (on the
FDC) to your external tape drive, you can get ftape
to control your tape drive.
This is because that from a program's view there is no
difference between the internal and the external connectors. So,
from ftape's point of view, they are identical.
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.
ftape
Unfortunately, some PCI motherboards cause problems when
running ftape. Some people have experienced that
ftape would not run in a PCI based box, but ran
flawlessly in a normal ISA based 386DX machine. If you have such
a problem, please read the README.PCI file in the
ftape distribution.
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.
This section describes some simple uses of tar
and mt. Other examples can be found in the
ftape-manual of the ftape-doc package.
The ftape-tools contains some simple automated
DejaGnu
Package for writing automated tests.test-suites. See section Getting ftape for informations about where to download those additional packages from.
You can use `tar', `dd',
`cpio', and `afio'. You will need to
use `mt' to get the full potential of your tapes and
the ftape driver. For a start I'd recommend using
`tar', as it can archive lots of directories and let
you pick out separate files from an archive. cpio
creates smaller archives and is more generally more flexible than
tar, but is missing some features like volume
labels. `afio' creates backups where each file is
compressed individually and then concatenated. This will allow
you to access the files ``after'' the point of the error. If you
use gzipped tar files, all data after
the point of the error is lost! (to me, this is a pretty good
reason for NOT using compression on backups). The choice of which
is most appropriate depends on the situation and the features and
malfeatures of each of the packages. I recommend taking a look at
each package at reviewing the options that each provides. It's
possible that this HOWTO may provide more detail on this subject
at some point in the future.
There are more links pointing to backup software at
http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/
in the software section of that page.
To make a backup of your kernel source tree using
tar, do this (assuming you have the sources in
/usr/src/linux):
# cd /usr/src # tar cf /dev/ftape linux
This will not compress the files, but gives you a smoother
tape run. If you want the compression (and you've got
tar 1.11.2), you just include the -z
flag(*), eg: `tar czf /dev/ftape linux'
For further instructions on how to use tar,
dd and mt look at the man pages and the
texinfo files that comes with the respective distributions.
(*) tar assumes that the first argument is
options, so the `-' is not necessary, i.e. these two
commands are the same: `tar xzf /dev/ftape' and
`tar -xzf /dev/ftape'
OK, let us restore the backup of the kernel source you made in section Writing an archive to a tape above. To do this you simply say
tar xf /dev/ftape
If you used compression, you will have to say
tar xzf /dev/ftape
When you use compression, gzip will complain
about trailing garbage after the very end of the archive (and
this will lead to a `broken pipe' message). This can be safely
ignored.
For the other utilities, please read the man page.
tar has an option (-d) for detecting differences
between two archives. To test your backup of the kernel source
say
tar df /dev/ftape
If you do not have the man page for tar, you are
not lost (yet); tar has a built-in option list: try `tar
--help 2>&1 | less'
To put more than one backup on a tape you must have the
mt utility. You will probably have it already, if
you got one of the mainline distributions (eg. Slackware or
Debian).
Programs like tar and cpio generate
a single Tape ARchive and know nothing about multiple files or
positioning of a tape, it just reads or writes from/to a device.
mt knows everything about moving the tape back and
forth, but nothing about reading the data off the tape. As you
might have guessed, combining tar or
cpio with mt does the trick.
By using the nqft[0-3] (nftape)
device, you can use `mt' to position the tape the
correct place (`mt -f /dev/nqft0 fsf 2' means step
over two ``file marks'', i.e. tar files) and then
use tar or cpio to read or write the
relevant data.
The most common use of the non-rewinding device is to append another backup to an existing tape. Here are the specific steps with a little explanation thrown in for good measure.
The tape should now be positioned at the End-of-Data (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 `mt -f /dev/n???? eof
mt eof' may be faster on
QIC tapes.
ftape uses the volume table as specified in
the 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.ftape caches some information that belongs in the
header segments on the tape and update those header segments
only when the tape is rewound. This caching is necessary
because rewinding the tape and updating the header segments
takes a 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.``Is there a way to extend an archive -- put a file on the tape, then later, add more to the tape?''
No. The tar documentation will tell you to use
`tar -Ar', but it does not work. This is a
limitation of the current ftape driver.
Since a tape does not have a ``filesystem'' on it, you do not
mount / unmount the tape. To backup, you just insert the tape and
run your `tar' command (or whatever you use to
access the tape with).
ftape
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
ftape.
This section was written by Claus Tøndering
<ct@login.dknet.dk>.
Once you are the happy owner of a tape drive and several tapes full of backups, you will probably ask yourself this question: ``If everything goes wrong, and I completely lose my hard disk, how do I restore my files from tape?''
What you need is an emergency floppy disk that contains enough files to enable you to boot Linux and restore your hard disk from tape.
The first thing you should do is to read ``The Linux Bootdisk HOWTO'' written by Graham Chapman <grahamc@zeta.org.au>. That document tells you almost everything you need to know about making an emergency floppy boot kit. The paragraphs below contain a few extra pieces of information that will make your life a bit easier when you follow Graham Chapman's procedures:
/etc/init,
/etc/inittab, /etc/getty, and
/etc/rc.d/* on your floppy disk. If Linux doesn't
find /etc/init, it will start /bin/sh
on your console, which is fine for restoring your system.
Deleting these files gives you extra space on your floppy,
which you will probably need./bin/sh. They are
frequently available on the boot floppies that come with a
Linux distribution. This again will give you extra space. I'd
suggest ash, which is extremely small (approx
62Kbytes), and yet very bash compatible./etc/fstab you include on your floppy disk
should look something like this:
Once you have booted from your floppy, give the command:/dev/fd0 / minix defaults none /proc proc defaults /dev/hda /mnt ext2 defaults
mount -av
This means that you MUST load the floppy into a RAMDISK. This has the unfortunate consequence that the programs needed to restore the files from the tape can not be located on a separate floppy disk. You have two options here:Unable to grab IRQ6 for ftape driver
tar (or cpio or
afio or whatever other backup program you use)
on your root floppy disk. (This is where you'll need all
the extra space created in the steps above.)tar (or cpio or afio
or whatever) to your hard disk and load it from there.mt on your root floppy as well./dev/nqft0) is present on your boot floppy.FAQ to the
sections of the original FAQ document.
This FAQ collection might be slightly out of data as it was
collected while version 3.04d of the 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
(<heine@math1.rwth-aachen.de>) as well as the maintainer of
the Ftape-FAQ (Johan De Wit <jo@correct.nl>) a
note
You might encounter references to the following addresses while reading this document:
<http://www.torque.net/ftape/>
Thanks to Grant R. Guenther <grant@torque.net>
<http://www.info-systems.com/ftape/>
Thanks to Jakob Curdes <jc@info-systems.com>
<http://www.newwave.net/~joshg/ftape/>
Thanks to Josh Goins <joshg@newwave.net>
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 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 maintainer of the Ftape FAQ AND to Ftape Mailing List.
If you make FAQ related postings, then please DON'T FORGET to prepend the word "[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.
Always the latest stable version which is _supposed_ to be available from ftp://sunsite.unc.edu/pub/Linux/kernel/tapes and http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/
At time of this writing the latest stable version is
ftape-4.02.
<answer from Claus Heine>
The default version of Ftape included in the 2.0.xx kernel sources is 2.08 or 2.09 and is very out of date. Please update the Ftape drivers to the latest from the Ftape Home Page.
<answer from Tim Jones>
You need to add -D__SMP__ to the
KERNEL_OPT variable in the file
MCONFIG. In newer ftape versions you
only need to uncomment a certain line in the MCONFIG
file.
<answer from Claus Heine>
Ignore the depmod error messages. The problem is that the
Ftape modules have to be compiled without the version
checksum feature (i.e. CONFIG_MODVERSIONS) with
2.0.* kernels. This causes no problem, even when the
modules are used with a kernel that has support for this feature;
only that depmod wrongly complains about undefined
symbols. Ignore the complaints of depmod and try to
insert the modules despite of these complaints:
If this fails, something is wrong.modprobe zftape
<answer from Claus Heine>
The insmod program can check the kernel version
against the version that Ftape was compiled for in two
ways: It can directly compare the kernel version number recorded
in the Ftape module against the version of the running
kernel, or, if both the kernel and Ftape is compiled
with versioned symbols, compare the version of the used kernel
symbols.
If you have upgraded your version of GCC to v2.7.0 or later, you must recompile the modules utilities with gcc v2.7.x.
Newer versions of insmod allows you to "force"
insertion of a module into the kernel, even though the version
string is incorrect.
<from the Ftape-Howto>
Did you remember to apply the ksyms.c patch to
the kernel? If not, read the README.linux-1.2 file
in the source distribution.
<from the Ftape-Howto>
The modversions.h file is created when the kernel
is compiled with the configuration item
CONFIG_MODVERSIONS turned on. With this option
enabled, the file will be created during the make
dep step.
One more handy tip is that a make mrproper will
remove /usr/include/linux/modversions.h. You will
need to reconfig the kernel and do a make dep to get
the file back.
<from the Ftape-Howto>
When you say `yes' to CONFIG_MODVERSIONS during
`make config', all the symbols exported by the
kernel, i.e: the symbols that the loadable modules can "see", are
augmented to include a checksum across the types of the
call/return parameters. This allows insmod to detect
whether the definition of a variable or function in the kernel
has changed since the time when Ftape was compiled.
This ensures a high degree of safety, such that you do not crash the kernel because you used an outdated module with your kernel.
If you enable CONFIG_MODVERSIONS in the kernel,
make sure you have
-DMODVERSIONS -include /usr/include/linux/modversions.huncommented in the MODULE_OPT line in the Ftape Makefile. Conversely, if you do not have CONFIG_MODVERSIONS enabled, make sure you have it commented out.
<from the Ftape-Howto>
There are (at least) two possible sources of the problem:
As/lib/modules/misc instead of /lib/modules/uname -r/misc
modprobe searches in
/lib/modules/misc/ last there might be an old
ftape.o module floating around in
/lib/modules/ uname
-r
/misc which modprobe finds
first (uname -r stands for the kernel version).
Remove the old ftape.o module.
CONFIG_FTAPE) and recompile and install it.<answer from Claus Heins>
You are probably trying to use the same IRQ and DMA settings as your on-board FDC. This does not work in versions of Ftape prior to 3.03b. Please update the Ftape Drivers to the latest from the Ftape Home Page.
<answer from Tim Jones>
Sadly to say there are some SVGA cards and Ethernet cards that
do not decode their addresses correct. This typically happens
when the Ftape buffers are in the range
0x1a0000 to 0x1c0000. Somehow, the DMA
write cycles get clobbered and every other byte written gets a
bad value (0xff). These problems are reported to
happen with both SVGA and Ethernet cards. We know of at least one
(bad?) ATI 16bit VGA card that caused this.
The easiest solution is to put the card in an 8bit slot (it is often not enough to reconfigure the card to 8bit transfers). Moving the Ftape buffer away from the VGA range is only a partial solution; All DMA buffers used in Linux can have this problem! Let us make this one clear: This has nothing to do with the Ftape software.
<from the Ftape-Howto>
You should only see this is you are trying to
insmod the ftape.o module. Try running
swapout first. It is provided with the standalone
Ftape source. It doesn't appear in the Ftape
source that's provided with the kernel.
Here's an example of how you can set your rc.local file to use it.
# Install the Floppy Tape Driver if [ -f /boot/modules/`uname -r`/misc/ftape.o ]; then echo Installing ftape for Linux `uname -r` swapout insmod /boot/modules/`uname -r`/misc/ftape.o fi
Please note that you won't have this type of problem if you compile the Ftape driver into the kernel.
<from the Ftape-Howto>
The compile-time options NO_TRACE and
NO_TRACE_AT_ALL in Ftape control the amount
of system logging. Add whichever is appropriate to the
FTAPE_OPT line in the Makefile and recompile.
<from the Ftape-Howto>
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.
/sbin/insmod ftape.o tracing=<tracing-level>
fsr option in
mt to be used to set the tracing level.
zftape does not have this hack.
The use of themt -f /dev/ftape fsr <tracing-level>
fsr command in
mt is a hack, and will probably
disappear or change with time.
tracing.c contains a line int tracing =
3;. Change the 3 to whatever is appropriate and
recompile.<From the Ftape-Howto>
Check the 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 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 Linux-Tape Mailing List , but do not attach your entire 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 Ftape maintainer will most likely request that you send him the entire Ftape error-log (snipped from your system messages file).
<answer from Tim Jones>
You can achieve quite respectable backup and restore speeds with Ftape: a Colorado DJ-20 and an Adaptec 1542CF controller, has been measured at 4.25Mbyte/min sustained data transfer rate (no compression) across a 70Mbyte tar archive, while comparing the archive on the tape with data on an IDE disk. The speed of Ftape is mostly dependent on the data transfer rate of your FDC: The AHA1542CF has a ``post-1991 82077'' FDC, and it will push 1Mbit/sec at the tape drive. If you have an FDC which can only deliver 500Kbit/sec data rates, you will see half the transfer rate (well, roughly).
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.
<from the Ftape-Howto>
Probably not. If you are backing up a large number of < 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
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.ftmt -f /dev/zqft0 reten
<answer from Tim Jones>
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:
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.find /usr/local -xdev -print | afio -o -v -f -b 10240 -c 800 /dev/qft0
Presumably other backup utilities could be modified to use a similar technique.
<answer by Michael Hamilton>
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 Ftape's builtin compression)
Another way to overcome the problem might be to use more dma buffers in the Ftape kernel driver like:
$((6*32786)) should be expanded by your shell when using a Bourne compatible one. This has a negative impact on the system's memory pool: 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.mt -f /dev/qft0 setdrvbuffer $((6*32786))
<answer by Claus Heine>
Not if you are using the latest version of the Ftape drivers from the Ftape Home Page.
To format a QIC-80, TR-1, TR-3, QICWide 3010 or 3020 tape, get
the latest version of ftape and the latest version
of the ftape-tools package (from the same location)
and read the documentation of the ftformat utility
which is included in the ftape-tools package.
<answers from Tim Jones and Claus Heine>
It isn't possible to format Ditto 2GB tapes with
Ditto 2GB tape drive, and it isn't possible at all
to re-format Ditto 2GB tapes in a way that they
still can be used by a Ditto 2GB tape drive.
This is a hardware limitation of the Ditto 2GB
tape drive. It can't be helped at the software level, i.e. it
isn't ftape's fault.
No, the Ditto Max can't format tapes.
This is a hardware limitation of the Ditto Max
(Pro) tape drive. It can't be helped at the software
level, i.e. it isn't ftape's fault.
If you look at the difference, you will notice that Ftape always detects 2784 sectors more than DOS.
The number that Ftape reports is correct (of course
:-). Each correctly formatted QIC-3020 tape has 2784
sectors at fixed positions that are marked in the bad sector map.
To quote from the specs:
Tracks 5,7,9,11,13,15,17,19,21,23,25 and 27 within 4 segments of either EOT or BOT are prone to increased error rates due to hole imprints. Therefore, these regions shall be mapped as bad at format time and entered in the bad sector map by indicating that all sectors within the identified segments are bad.
This gives 12 tracks * 2 * 4 segments * 29 sectors == 2784 sectors.
So Ftape choose to report the real number of sectors that cannot be used on the tape, while DOS gives a more optimistic number giving a better indication of tape quality. (Ftape's behavior might change in the future to detect correct formatting and display the separate numbers. It has rather low priority though).
QIC-3010 are alike QIC-3020 tapes regarding this.
<from the Ftape-Howto>
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.
<from the Ftape-Howto>
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:
mt -f /dev/qft0 setblk 5120
to switch 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 Ftape (it _may_ work, don't know if it does)mt -f /dev/qft0 setblk 0
afio -b 10k ...
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
--block-compress switch to re-block the
output to the tape. Otherwise tar will compress the data it
reads, and write it in arbitrary portions to the tape.
Example : tar -czvf /dev/qft0 --block-compress /etc
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.
<answer by Claus Heine>
When you get next messages, this could be interesting for you !
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.
<answer from Claus Heine>
I assume that the following is the problem: The Ftape module is loaded OK into the kernel:
but then this happens:/usr/src/ftape-3.03b-970603# lsmod Module Pages Used by ftape 22 0
$ ftmt -f /dev/qft0 status ftmt: /dev/qft0: No such device
Solution You need to load the zftape.o module as well. With Ftape-3.* the ftape.o module doesn't implement the VFS interface. This is done by zftape.o.
<answer from Claus Heine>
The "device busy" messages can only occur while the 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:
You can skip the "--block-compress" if using the most recent version of GNU tar.tar -cvvzf /dev/nqft0 --block-compress ; mt rewind
However, this is not a bug of 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.
tar - fork() - write to child tar | child tar - fork() - gzip (will pipe to grand child tar) | grand child tar - open archive.
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 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.
<answer from Claus Heine>
These are really tar questions: Please read the
man page and the info page. If you have
not got it either, try
tar --help 2>&1 | less
If your version of tar is v1.11.1 or earlier,
consider upgrading to v1.11.8 - This version can call GNU
zip directly (i.e.: it supports the -z
option) and has an elaborate help included. Also, it compiles
right out of the box on Linux.
<from the Ftape-Howto>
When using compression, and in all general, it can be a
benefit to specify to tar, that it should block the
output into chunks. Since Ftape cuts things into 29Kbyte
blocks, saying `-b58' should be optimum.
"Why 29Kbyte?", I hear you cry. Well, the QIC-80 standard specifies that all data should be protected by an Error Correcting Code (ECC) code. The code specified in the QIC-80 standard is known as a Reed-Solomon (R-S) code. The R-S code takes 29 data bytes and generates 3 parity bytes. To increase the performance of the ECC code, the parity bytes are generated across 29 1Kbyte sectors. Thus, Ftape takes 29Kbytes of data, adds 3Kbytes of ECC parity, and writes 32Kbytes to the tape at a time. For this reason, Ftape will always read and write 32K byte blocks to be able to detect (and correct) data errors.
If you are curious, and wish to know more, look in the
ecc.c and ecc.h files, for an
explanation of the code and a reference to a textbook on
Reed-Solomon codes.
<from the Ftape-Howto>
All of these tools have been developed by the GNU project, and
the source (and man page) can be fetched from just-about any ftp
site in the world (including ftp.funet.fi,
tsx-11.mit.edu, and sunsite.unc.edu).
In any case they can be fetched from the official GNU home site:
prep.ai.mit.edu [18.71.0.38]:/pub/gnu. The latest
versions (as of September 12 1996) are:
cpio: 2.4.2 (cpio-2.4.2.tar.gz) dd: 3.13 (fileutils-3.13.tar.gz) mt: 2.4.2 (cpio-2.4.2.tar.gz) tar: 1.11.8 (tar-1.11.8.tar.gz) gzip: 1.2.4 (gzip-1.2.4.tar.gz)
They all compile out of the box on Linux v1.0.4 /
libc v4.5.19 / gcc v2.5.8.
<from the Ftape-Howto>
It is not bad as such to compress data twice (which would be the case when using tapers compression together with 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 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.
<Answer from Claus Heine>
gzip -9 is better (i.e. one gains higher compression). zftape's compression is comparable with the Un*x compress program, but should be faster, and is faster than gzip.
<Answer from Claus Heine>
Use the zftape interface, but don't load the
zft-compressor module. The device then becomes
/dev/qft0.
<answer from Tim Jones>
You get this complaint if you haven't erased your freshly formatted tape. This is because Ftape expect a "magic header" on the tape, to be able that it is allowed to interpret the header segment in its own way (eg: file marks). To remove the problem, say
mt -f /dev/nftape erase
<from the Ftape-Howto>
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.
<From the Ftape-Howto>
(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.
<from the Ftape-Howto> <Answer from Claus Heine>
It probably didn't work before because you didn't use a
before writing data to the cartridge. THIS ISN'T necessary any more.mt -f /dev/rft0 erase
But, hey, what does mt fsf? Tape drives don't store files in the sense that you can use
cp somefile /dev/my_what_ever_tapeor 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 file mark or 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.
would result in a backup of all files under /bin and /etc. When the first tar finishes, the kernel driver will take care of writing a file mark to the tape at the the current tape position, and when the second tar process has finished, another file mark is written to the tape cartridge at that position.tar -cf /dev/nqft0 /bin tar -cf /dev/nqft0 /etc mt -f /dev/nqft0 rewind
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:
fast skip to the next file mark towards EOT (End Of Tape)
fast skip to the next file marks towards BOT (Begin Of Tape)
mt -f /dev/nqft0 rewind mt -f /dev/nqft0 fsf tar -xvf /dev/nqft0
<Answer from Claus Heine>
When Ftape was young there were two versions of the floppy tape driver, one of them was called 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 zftape was much better and had less bugs. And zftape allows to use floppy tape cartridges with different OS. Well, you can't exchange data, but zftape won't overwrite volumes created by your Windoze program, and vice versa.
Nowadays, Ftape is name of the entire floppy tape driver package AND ftape.o is the file-name of the kernel module that implements the low-level hardware support. zftape has ceased to exist as a separate package, but the new Ftape versions (since ftape-3.00) contain a zftape.o module that needs to be loaded on top of 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 zftape.
<Answer from Claus Heine>
Well, the rewinding tape devices rewind the tape to BOT (Begin Of Tape) when the device is closed, i.e.
will rewind the tape cartridge when the tar job has finished. In contrast,tar -cvf /dev/qft0 /bin
will NOT rewind the tape cartridge and leave the tape R/W head at its current position.tar -cvf /dev/nqft0 /bin
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
, because when the mt process finishes then the tape device is closed which would result in rewinding the cartridge with the rewinding devices.mt -f /dev/nqft0 fsf
<Answer from Claus Heine>
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
EOT side of the last skipped file mark. This means,
an "mt bsf 2" will position right at the beginning of the
previous volume.
<answer form Claus Heine>
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).
<answer form Claus Heine>
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 zftape every read and write access has to be a
multiple of a fixed block size (fixed, but tunable with
MTSETBLK). This block size is a "tape record" (as
mentioned in the GNU mt man page and defaults to 10kb for
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 BOT or the file
mark of the previous tape "file". That tape "files" are the
things that can be skipped with the MTBSF/FSF
commands.
<answer form Claus Heine>
We try to answer the followong questions :
If you want to "erase" an entire cartridge, then simply do:
mt -f /dev/qft0 erase
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
vtblc
program that comes with the ftape-tools package
which can be down-loaded from the same locations as the
ftape kernel driver package. Please refer to the
documentation which is contained in the ftape-tools
package for more information.
If you simply want to reuse old tapes, then it suffices to do
mt rewind
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.
<answer by Claus Heine>
Here is as little perl/bash script that lists the contents of a cartridge using the zftape specific "volinfo" ioctl. Hope this shows how to handle this kind of stuff.
What it basically does is the following:
Parse the ouput and place the values in appropriate variablesclaus@thales:~$ mt volinfo file number = 1 block size = 10240 physical space used = 522.0 kilobytes real size of volume = 520.0 kilobytes
The Perl Script
#!/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: 1.2 $ RCS \$Date: 1998/08/30 13:44:03 $ 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] =~ /^-/) { $_ = shift; if (/--file/) {$_ = shift; $tapedev = $_; next;} if (/-f/) {$_ = shift; $tapedev = $_; next;} if (/--help/) { print $usage; exit 0; } if (/-h/) { print $usage; exit 0; } if (/--usage/) { print $usage; exit 0; } if (/-\?/) { print $usage; exit 0; } if (/--version/) { print $version; exit 0; } if (/-V/) { print $version; exit 0; } die $usage; } &open_tape($tapedev, "status"); while(<FTMT>) { $online = 1 if (/.*online.*/); } if (! $online) { die "No cartridge present.\n"; } &mtop($tapedev, "rewind"); printf "%11s%12s%20s%20s\n", "file number", "block size", "volume size", "tape space"; while (1) { &open_tape($tapedev, "volinfo"); while (<FTMT>) { if (/^file number\s*=\s*([0-9]*)$/) { $filenumber = $1; } if (/^block size\s*=\s*([0-9]*)$/) { $blocksize = $1; } if (/^physical space used\s*=\s*([[0-9]*.*)/) { $rawsize = $1; } if (/^real size of volume\s*=\s*([[0-9]*.*)/) { $size = $1; } } close(FTMT); if (&mtop($tapedev, "fsf 1") != 0) { &mtop($tapedev,"rewind"); print "\nRemaining space: $rawsize\n"; print "Tape block size: $blocksize\n"; exit 0; } printf "%6d %5d %20s%20s\n", $filenumber, $blocksize, $size, $rawsize; } sub mtop { local ($tape, $operation) = @_; local ($exitval); system "ftmt -f $tape $operation > /dev/null 2>&1"; } sub open_tape { local ($tape, $operation) = @_; local ($command); $command = "ftmt -f " . $tape . " " . $operation . " |"; open(FTMT, $command) || die "Couldn't open $command -- $!\n"; }
The Bash Script
#! /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=${1-/dev/tape}
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>&2
exit 1
fi
if ! mt -f $TAPEDEV rewind
then
echo Could not rewind $TAPEDEV - no cartridge present? 1>&2
exit 1
fi
echo -e "\nContents of $TAPEDEV:\n"
printf "%11s%12s