ftape-HOWTO <author>Kai Harrekilde-Petersen, <htmlurl url="mailto:khp@pip.dknet.dk" name="<khp@pip.dknet.dk>"> <date>v1.53, 2 July 1995 for ftape-2.03b <abstract> This HOWTO discuss the essentials of the do's and dont's for the <tt>ftape</tt> driver under Linux. The <tt>ftape</tt> driver interfaces to QIC-40, QIC-80, QIC-3010 and QIC-3020 compatible drives only. The QIC-3010 and QIC-3020 standards are also known as `QIC-WIDE'. These drives connects via the floppy disk controller (FDC). It <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 <url url="http://sunsite.unc.edu/mdw/HOWTO" name="the Linux HOWTO index">, while the real HOWTO's can be fetched (using <tt>ftp</tt>) from <tt>sunsite.unc.edu:pub/Linux/doc/HOWTO</tt> (this is the ``official'' place) or via the World Wide Web from <url url="http://sunsite.unc.edu/mdw/linux.hmtl" name="the Linux Documentation Project home page">. </abstract> <toc> <sect>Legalese This is the `Frequently Asked Questions' (FAQ) / HOWTO document for the <tt>ftape</tt> driver (ftape-HOWTO), Copyright (C) 1993, 1994, 1995 Kai Harrekilde-Petersen. <bf>Copyright statement:</bf> You may distribute this document freely <bf>as a whole</bf> in any form and free of charge. You may distribute parts of this document, provided this copyright message is included and you include a message stating that it is not the full HOWTO document and a pointer to where the full document can be obtained. Specifically, it may be included in commercial distributions, without my prior consent. However, I would like to be informed of such usage. You may translate this HOWTO into any language, whatsoever, provided that you leave this copyright statement and the disclaimer intact, and that you append a notice stating who translated the document. <bf>DISCLAIMER:</bf> While I have tried to include the most correct and up-to-date information available to me, I cannot guarantee that usage of the information in this document does not result in loss of data. I provide NO WARRANTY about the information in the HOWTO and I cannot be made liable for any consequences for any damage resulting from using information in this HOWTO. <sect>News flash <bf>IMPORTANT:</bf> The <tt>ftape</tt> discussion forum has moved per May 11th, 1995 from the <tt>niksula.hut.fi</tt> server to the <tt>linux-tape</tt> list on <tt>vger.rutgers.edu</tt>. Please turn to the section <ref id="tape-channel" name="Following the ftape development"> on how to leave the <tt>niksula</tt> channel and subscribe to the <tt>vger</tt> list. This isn't exactly news, but anyway: The ascii and HTML versions have some of the section headers permuted. This is a feature of the SGML system that the LDP project uses. I can't help it. <descrip> <tag>version 1.53 (July 2, 1995)</tag> <itemize> <item> Section on the <tt>modules</tt> updated to v<tt>1.2.8</tt> <item> The index in the LaTeX'ed versions are now correct (thanks to an updated SGML system) <item> IOmega Ditto Tape Insider 1700 drive added. </itemize> <tag>version 1.52 (June 11, 1995)</tag> <itemize> <item> Correction of spelling and typos. </itemize> <tag>version 1.51 (May 13, 1995)</tag> <itemize> <item> Updated to <tt>ftape-2.03b</tt> <item> Included patch for timeouts on long tapes (QIC-WIDE) </itemize> <tag>version 1.5 (May 11, 1995)</tag> <itemize> <item> Updated to <tt>ftape-2.03a</tt> <item> The <tt>ftape</tt> discussion list has moved to <tt>linux-tape@vger.rutgers.edu</tt> <item> Conner TSM850R added to list of drives <item> Colorado FC-20 controller works as of v2.03 </itemize> <tag>version 1.41 (Apr 1, 1995)</tag> <itemize> <item> More bad English corrected, thanks to Daniel Barclay (I'm not a native speaker <tt>:-)</tt> </itemize> <tag>version 1.4 (Mar 17, 1995)</tag> <itemize> <item> Mostly typos corrected. </itemize> </descrip> <sect>The preliminaries Note that I (the howto-maintainer) no longer use <tt>ftape</tt> myself, so I cannot give much up-to-date advice on e.g. compiling <tt>ftape</tt>. If you have a problem, try posting on <tt>comp.os.linux.help</tt>, or to the tape discussion list on <tt>vger.rutger.edu</tt> (see <ref id="tape-channel" name="Following the ftape development"> below). You should try to post a summary of your problems and its solution(s), after you've got it working, even if you only got it partially working. Please also send me (<tt><khp@pip.dknet.dk></tt>) a copy of your solution so that I can add it to the HOWTO. I read my mail daily, I try to respond to everyone, but I cannot guarantee that I will respond immediately. Also, I seldomly read the newsgroups (<tt>comp.os.linux.help</tt> et al), as my Internet access is through a modem line and I have to read news On-line <tt>8-(</tt>. If you recieve this as part of a printed distribution or on a CD-ROM, please check out <url url="http://sunsite.unc.edu/mdw/linux.hmtl" name="the Linux Documentation home page"> or ftp to <tt>sunsite.unc.edu: /pub/Linux/doc/HOWTO</tt> to see if there exists a more recent version. This could potentially save you a lot of troubles.  <sect>Getting and installing <tt>ftape</tt> I will eventually include an installation guide in this section. You'll have to do without it, for the moment being. <sect1>What is <tt>ftape</tt> <tt>ftape</tt> is a driver program that controls various low-cost tape drives that connect to the floppy controller. <tt>ftape</tt> 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 file <tt>/dev/[n]rft[0-3]</tt>. <tt>ftape</tt> is written by Bas Laarhoven <tt><bas@vimec.nl></tt>, with ``a little help from his friends'' to sort out the ECC (Error Correcting Code) stuff. <tt>ftape</tt> 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</tt> is currently beta testing, and has been that for some time now. It is reliable enough for critical backups (but always remember to check your backups, so you won't get a nasty surprise some day). <tt>ftape</tt> supports drives that conform to the QIC-117 and one of the QIC-80, QIC-40, QIC-3010, and QIC-3020 standards. <tt>ftape</tt> does <bf>not</bf> support QIC-02 tape drives or drives that connect via a SCSI interface, e.g. DAT 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</tt>. See section <ref id="supp_drives" name="Supported drives"> and <ref id="unsupp_drives" name="Un-supported drives"> for a list of supported and unsupported drives. <sect1>How fast is <tt>ftape</tt>? You can achieve quite respectable backup and restore speeds with <tt>ftape</tt>: I have a Colorado DJ-20 and an Adaptec 1542CF controller, and have measured a 4.25Mbyte/min sustained data transfer rate (no compression) across a 70Mbyte tar archive, while comparing the archive on the tape with data on my IDE disk. The speed of <tt>ftape</tt> 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>What you need to install <tt>ftape</tt> There are three source distributions that you must have to get <tt>ftape</tt> running: <itemize> <item> <tt>ftape</tt> v2.03 / v2.03a <item> <tt>modules</tt> v1.1.87 <item> Linux kernel v1.2.<something> </itemize> <sect2>Getting <tt>ftape</tt> <tt>ftape</tt> can be fetched from the following site (and its mirrors): <tscreen><verb> sunsite.unc.edu [152.2.22.81]: /pub/Linux/kernel/tapes/ </verb> </tscreen> You should get the files: <tt>ftape-2.03.tar.gz</tt>, <tt>ftape-2.03a-patch.gz</tt> and <tt>ftape-lsm</tt>. The <tt>.tar.gz</tt> and <tt>patch.gz</tt> files are the <tt>ftape</tt> driver proper, while the <tt>lsm</tt> file is a Linux Software Map (LSM) file for the LSM project. The following patch, which corrects timeouts on long tapes, was sent out by Bas on the Linux Tape list on May 13th: <tscreen><verb> --- 1.29 1995/05/10 16:09:36 +++ ftape-read.c 1995/05/12 17:36:37 @@ -478,10 +478,10 @@ case QIC_TAPE_QIC80: segments_per_1000_inch = 488; break; - case QIC_TAPE_QIC3020: + case QIC_TAPE_QIC3010: segments_per_1000_inch = 730; break; - case QIC_TAPE_QIC3010: + case QIC_TAPE_QIC3020: segments_per_1000_inch = 1430; break; } </verb></tscreen> <sect2><tt>modules</tt> Newer kernels (from 1.1.85 and on), have improved support for loadable modules (by Bjørn Ekwall and Jacques Gelinas), which (if possible) allows you to insert modules compiled for an `old' kernel into a `new' kernel. To compile the kernel with this improved module support, you need the <tt>modules-1.2.8.tar.gz</tt> file. The modules packages can be found on <tt>tsx-11.mit.edu</tt> and <tt>sunsite.unc.edu</tt>. You must compile and install it before you compile the kernel. <sect3>What's new in <tt>modules-1.2.8</tt>? The v<tt>1.2.8</tt> package no longer exhibits the infamous <tt>insmod</tt> Oops bug, when <tt>ftape</tt> is inserted into the kernel. This was, by the way, caused because <tt>insmod</tt> did not handle modules with more that 4Kbyte of static data correctly. However, this is not the greatest advantage of the v<tt>1.2.8</tt> package. With v<tt>1.2.8</tt> comes the <tt>kerneld</tt> daemon which can automatically insert the needed modules as needed. This requires a patch to the v<tt>1.2.x</tt> kernels, but the patch is supposed to be included as a standard part of the kernel, when the <tt>1.3</tt> kernel series starts. <sect3>Installing <tt>modules-1.1.87</tt> Although you still can use version <tt>1.1.87</tt> of the modules utilities, I recommend that everyone upgrade to the <tt>1.2.8</tt> version. If do not wish to upgrade (or cannot), here is what to remember when installing the <tt>1.1.87</tt> version: The <tt>modules-1.1.87</tt> package has a bug which will cause the <tt>insmod</tt> to generate a kernel Oops, which the <tt>ftape</tt> modules is inserted. This bug is corrected by the <tt>insmod.c</tt>, <tt>insmod.h</tt>, and <tt>load_aout.c</tt> files that you can find in the <tt>ftape-2.03/insmod</tt> directory. (From now on, mail about <tt>Oops</tt>'es when <tt>ftape</tt> is inserted will quietly go to <tt>/dev/null</tt>). <sect2>The Linux kernel Since Linux version 1.2 has been out for some time I assume that everyone has switched over to it. If you have not already switched over, I assume you have a very good reason for not doing so, and that you can cope with the differences in installation etc, that it will make for you. The kernel can be fetched from a large number of sites all over the world, including these: <tscreen><verb> sunsite.unc.edu [152.2.22.81]: /pub/Linux/kernel/tapes/ tsx-11.mit.edu [18.172.1.2]: /pub/linux/sources/system/ ftp.funet.fi [218.214.248.6]: /pub/OS/Linux/PEOPLE/Linus/ </verb> </tscreen> You will find a number of subdirectories, including two named <tt>v1.1</tt> and <tt>v1.2</tt>. These contain (you guessed it!) <tt>v1.1</tt> and <tt>v1.2</tt> of the kernel. I suggest that you get version <tt>1.2.x</tt>. <sect1>If you have <tt>ftape-2.02</tt>, or earlier Since <tt>ftape</tt> both has been improved and some more bugs have been thrown out, you should consider upgrading to <tt>2.03b</tt> mandatory. <sect1><label id="tape-channel">Following the development of the <tt>ftape</tt> driver If you want to follow the development of the <tt>ftape</tt> driver, you should consider subscribing to the TAPE mailing list on <tt>vger</tt>. To subscribe to it, send a mail saying `<tt>subscribe linux-tape</tt>' to <tt>majordomo@vger.rutgers.edu</tt>. 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>Note for old users:</bf> On May 11th, Bas announced (together with the 2.03a patch) that the `official' mailing list from now on will we the <tt>linux-tape</tt> list on <tt>vger</tt>. Hence, all that are on the Linux-activists list on Niksula should move to the other list. Since I once in a while see mail of the type ``Help! I can't get off niksula'', I am going to be a bit elaborate on how to get off (and what to do before despairing). To get off the TAPE channel on Niksula, you send a mail to <tt><linux-activists-request@niksula.hut.fi></tt> with the line `<tt>X-Mn-Admin: leave TAPE</tt>'. If Niksula refuses, try sending a mail with the line `<tt>X-Mn-Info: user <yourloginname></tt>'. This should return you a mail which tells you under what email address you are subscribed. The Niksula mailer is very adamant on the point that you must unsubscribe with the same email address that you used to subscribe originally. If the machine that you originally subscribed with has changed its address, you can try to fake the mail by adding the line `<tt>From: <foo@bar.site.edu></tt>' right before or after the `leave TAPE' line. This should fool niksula into unsubscribing you. As a very last resort, you could talk someone into logging into the SMTP port on niksula and creating a faked mail. <sect1>Compiling and installing the <tt>ftape</tt> driver There is included an installation guide (the file <tt>Install-guide</tt>) in the <tt>ftape</tt> distribution; please read that. <sect1>Can I format my tapes under Linux? No! Honestly, noone is working on it: If you want to work on it, drop Bas a line. Until then, you'll have to use MessyDOS (arghhh!) instead or buy preformatted tapes. However, some of the preformatted tapes are not checked for bad sectors!. If the <tt>ftape</tt> driver encounters a tape with no bad blocks, it will issue a warning. If <tt>ftape</tt> barfs at your preformatted tapes, try out your DOS software. If both the DOS software and <tt>ftape</tt> barfs on your tapes, a reformat will very probably cure the problem. Note that to be able to use your newly formatted tapes under ftape, you must erase the tape first: <tscreen><verb> mt -f /dev/nftape erase </verb></tscreen> <sect1>Which formatting programs can I use under DOS? These are known to work: <itemize> <item> Colorado Memory System's software (<tt>tape.exe</tt>) <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</tt> -- 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> In fact, 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</tt> detects this, and will work around it. Dennis T. Flaherty (<tt><dennisf@denix.elk.miles.com></tt>) 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</tt> 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 (<tt><khp@pip.dknet.dk></tt>), so I can update the HOWTO. <sect1>Mixing <tt>ftape</tt> and floppies Since both the floppy driver and <tt>ftape</tt> needs the FDC (and IRQ6), they cannot run concurrently. Thus, if you have mounted a floppy and then try to access the tape drive, <tt>ftape</tt> 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 FDC's.  <sect>(Un)supported hardware <sect1><label id="supp_drives">Supported tape drives All drives that are both QIC-117 compatible and either QIC-40 or QIC-80 compatible should work. There are also experimental support of QIC-3010 and QIC-3020 drives (QIC-3010/302 can use 8mm tapes. This is sometimes refered to as `QIC-WIDE'). Currently, the list of drives that are known to work with <tt>ftape</tt> is: <itemize> <item> Alloy Retriever 250 <item> Archive 5580i / XL9250i <item> Colorado DJ-10 / DJ-20 (aka: Jumbo 120 / Jumbo 250) <item> Conner C250MQ <item> Conner TSM420R <item> Conner TSM850R <item> Escom / Archive (Hornet) 31250Q <item> Insight 80Mb <item> Iomega 250 <item> IOmega Ditto Tape Insider 1700 (other Ditto drives probably work too) <item> Mountain FS8000 <item> Summit SE 150 / SE 250 <item> Tallgrass FS300 (needs a tiny hack to work with AHA1542B) <item> Memorex tape drive backup system <item> Wangtek 3080F </itemize> You can always check out the newest list of drives that are recognised by <tt>ftape</tt>, by looking in the file <tt>vendors.h</tt> in the <tt>ftape</tt> distribution. Although I do not want to endorse one drive type over another, I want to mention 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. I can't tell for sure, but I have a Colorado, and it is quite noisy). 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><klanvi@uta.fi></tt>), says that changing <tt>CMD_BUSON_TIME</tt> to 4 and <tt>CMD_BUSOFF_CMD</tt> to 12 in <tt>linux/drivers/scsi/aha1542.c</tt> will do the trick. One user has reported that <tt>ftape</tt> works (partially) the with Conner TSM420R drive, which supports both QIC-80 (normal) and `QIC-WIDE' tapes. As of right now, <tt>ftape</tt> provides only <bf>experimental</bf> support for QIC-WIDE tapes, and you should be aware of this. Hopefully, the TSM420R drive, and other QIC-WIDE drives, will be supported fully soon. If you have a drive that can use QIC-WIDE tapes, are interested in getting it to work with <tt>ftape</tt>, and not afraid of being ALPHA tester, drop Bas <tt><bas@vimec.nl></tt> a mail, stating which drive you have. NOTE: If you have a drive that works fine, but it is not listed here, please send a mail to the HOWTO maintainer (<tt><khp@pip.dknet.dk></tt>). <sect1>Supported special controllers These dedicated high-speed tape controllers are supported by <tt>ftape</tt>: <itemize> <item> Colorado FC-10 <item> Colorado FC-20 <item> Mountain MACH-2 <item> IOmega Tape Accelerator II </itemize> Support for the FC-10 controller has been merged into the <tt>ftape</tt> driver in version 1.12. See the <tt>RELEASE-NOTES</tt> and the <tt>Makefile</tt> files in the <tt>ftape</tt> distribution. Since of version 2.03 of <tt>ftape</tt>, the FC-20 controller will work (but do check the Release notes!). The support for the MACH-2 controller was added in <tt>ftape-1.14d</tt>. To use the IOmega Tape Accelerator II, use <tt>-DMACH2</tt>, and set the right settings for I/O base, IRQ and DMA. This works (by the empirical testing of Scott Bailey <tt><sbailey@xcc.mc.xerox.com></tt>), with at least <tt>ftape-2.02</tt>. <bf>Anti-Colorado message:</bf> As of lately, Colorado has proved themselves totally unwilling to help with FC-10 and FC-20 support. This is sad, and can only force me to say: Don't buy a Colorado high-speed controller, or even a Colorado tape drive. Why support a manufacturer who does not want to support his own product? <sect1><label id="unsupp_drives">Un-supported tape drives <itemize> <item> All drives that connect to the parallel port (eg: Colorado Trakker) <item> High-Speed controller's. (eg: Colorado TC-15 & FC-20) <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> Generally, ALL drives that connect to the parallel port are NOT supported. This is because these drives uses (different) proprietary interfaces, that are very much different from the QIC-117 standard. The Colorado TC-15 controller (and its like) are not supported directly by the <tt>ftape</tt> driver. The only `special' controllers that can be used with <tt>ftape</tt> is the Colorado FC-10 and the Mountain MACH-2 (see above). The Irwin AX250L (and the IBM Internal Tape Backup Unit) does not work the <tt>ftape</tt>. 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</tt> 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</tt>. 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 a quick glance on an FDC that I've got lying around, it seems to be a straight 1-to-1 cable. However, your milage may vary) from the DB37 connector (on the FDC) and to your external tape drive, you can get <tt>ftape</tt> 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</tt>'s point of view, they are identical. <sect1><label id="pci-boxes">Getting PCI motherboards to work with <tt>ftape</tt> Unfortunately, some PCI motherboards cause problems when running <tt>ftape</tt>. Some people have experienced that <tt>ftape</tt> would not run in a PCI based box, but ran flawlessly in a normal ISA based 386DX machine. To quote from the <tt>RELEASE-NOTES</tt> file in the <tt>ftape</tt> distribution: <tscreen><verb> More PCI news: -------------- There have been more reports about PCI problems, some of them were solved by upgrading the (flash) BIOS. Other rumours are that it has to do with the FDC being on the PCI bus, but that is not the case with the Intel Premiere boards. Here is a list of systems and the BIOS versions known to work: board: bios revision: Intel Premiere PCI (Revenge) 1.00.09.AF2 Intel Premiere PCI II (Plato) 1.00.08.AX1 (disable GAT in BIOS!) 1.00.10.AX1 To see if you're having the GAT problem, try making a backup under DOS. If it's very slow and often repositions you're probably having this problem. PCI news: --------- There have been some problem reports from people using PCI-bus based systems getting overrun errors. I wasn't able to reproduce these until I ran ftape on a Intel Plato (Premiere PCI II) motherboard with bios version 1.00.08AX1. It turned out that if GAT (Guaranteed Access Timing) is enabled (?) ftape gets a lot of overrun errors. The problem disappears when disabling GAT in the bios. Note that Intel removed this setting (permanently disabled) from the 1.00.10AX1 bios ! It looks like that if GAT is enabled there are often large periods (greater than 120 us !??) on the ISA bus that the DMA controller cannot service the floppy disk controller. I cannot imagine this being acceptable in a decent PCI implementation. Maybe this is a `feature' of the chipset. I can only speculate why Intel choose to remove the option from the latest Bios... The lesson of this all is that there may be other motherboard implementations having the same of similar problems. If you experience a lot of overrun errors during a backup to tape, see if there is some setting in the Bios that may influence the bus timing. </verb></tscreen>  <sect>Backing up and restoring data This section describes some simple uses of <tt>tar</tt> and <tt>mt</tt>. <sect1><label id="write-backup"> Writing an archive to a tape You can use `<tt>tar</tt>', `<tt>dd</tt>', `<tt>cpio</tt>', and `<tt>afio</tt>'. You will need to use `<tt>mt</tt>' to get the full potential of your tapes and the <tt>ftape</tt> driver. For a start I'd recommend using `<tt>tar</tt>', as it can archive lots of directories and let you pick out seperate files from an archive. I have been told that <tt>cpio</tt> creates smaller archives and is more flexible than <tt>tar</tt>, but I haven't tried it myself. `<tt>afio</tt>' 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</tt>ped <tt>tar</tt> 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). To make a backup of your kernel source tree using <tt>tar</tt>, 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</tt> 1.11.2), you just include the <tt>-z</tt> flag(*), eg: `<tt>tar czf /dev/ftape linux</tt>' For further instructions on how to use <tt>tar</tt>, <tt>dd</tt> and <tt>mt</tt> look at the man pages and the texinfo files that comes with the respective distributions. (*) <tt>tar</tt> assumes that the first argument is options, so the `<tt>-</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 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</tt> 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 tar has an option (<tt>-d</tt>) 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</tt>, you are not lost (yet); tar has a builtin option list: try `<tt>tar --help 2>&1 | more</tt>' <sect1>Putting more than one <tt>tar</tt> file on a tape To put more than one <tt>tar</tt> file on a tape you must have the <tt>mt</tt> utility. You will probably have it already, if you got one of the mainline distributions, e.g.\ Slackware or Debian. <tt>tar</tt> generates a single Tape ARchive (that's why it is called `<tt>tar</tt>') and knows nothing about multiple files or positioning of a tape, it just reads or writes from/to a device. <tt>mt</tt> knows everyting about moving the tape back and forth, but nothing about reading the data off the tape. As you might have guessed, <tt>tar</tt> and <tt>mt</tt> in conjunction, does the trick. By using the <tt>nrft[0-3]</tt> (<tt>nftape</tt>) device, you can use `<tt>mt</tt>' to position the tape the correct place (`<tt>mt -f /dev/nftape fsf 2</tt>' means step over two ``file marks'', i.e.\ <tt>tar</tt> files) and then use <tt>tar</tt> to read or write the relevant data. <sect1>Appending files to an archive ``Is there a way to extend an archive -- put a file on the tape, then later, add more to the tape?'' No. The <tt>tar</tt> documentation will tell you to use `<tt>tar -Ar</tt>', but it does not work. This is a limitation of the current <tt>ftape</tt> driver. <sect1>Mount/unmounting tapes Since a tape does not have a ``filesystem'' on it, you do not mount / unmount the tape. To backup, you just insert the tape and run your `<tt>tar</tt>' command (or whatever you use to access the tape with).  <sect>Creating an emergency boot floppy for <tt>ftape</tt> This section was written by Claus Tøndering <tt><ct@login.dknet.dk></tt>. 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 <tt><grahamc@zeta.org.au></tt>. 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. <item> The <tt>/etc/fstab</tt> you include on your floppy disk should look like this: <tscreen><verb> /dev/fd0 / minix defaults none /proc proc 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 implies 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 must not be located on a separate floppy disk. You have two options here: <enum> <item> You place tar (or cpio or afio or whatever other backup program you use) on your root floppy disk. (This is where you'll need all the extra space created in the steps above.) <item> Before you start restoring from tape, copy <tt>tar</tt> (or <tt>cpio</tt> or <tt>afio</tt> or whatever) to your hard disk and load it from there. </enum> <item> Apart from your backup program, you will probably need <tt>mt</tt> on your root floppy as well. <item> Make sure your ftape device (typically <tt>/dev/nrft0</tt>) is present on your boot floppy. <item> Finally: <bf>TRY IT!</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>  <sect>Frequently Asked Questions This is a collection of questions I get asked once in a while, which could fall into the category of FAQ's. If you feel that there is some question that ought to be added to the list, please feel free to mail me (but do include an answer, thanks!). <sect1>Can I exchange tapes with someone using DOS? No. The DOS software conforms to the QIC-80 specs about the layout of the DOS filesystem, and it should(?) be a small problem to write a program that can read/write the DOS format. In fact, I'd bet that creating a nice user interface would be a bigger problem. <sect1>How do I `....' with <tt>tar</tt>? These are really <tt>tar</tt> questions: Please read the <tt>man</tt> page and the <tt>info</tt> page. If you have not got it either, try `<tt>tar --help 2>&1 | more</tt>'. If your version of <tt>tar</tt> is v1.11.1 or earlier, consider upgrading to v1.11.2 - This version can call <tt>GNU zip</tt> directly (i.e.: it supports the <tt>-z</tt> option) and has an elaborate help included. Also, it compiles right out of the box on Linux. <sect1><tt>ftape</tt> DMA transfers gives ECC errors Sadly to say there are some SVGA cards and ethernet cards that do not decode their addresses correct. This typically happens when the <tt>ftape</tt> buffers are in the range <tt>0x1a0000</tt> to <tt>0x1c0000</tt>. Somehow, the DMA write cycles get clobbered and every other byte written gets a bad value (<tt>0xff</tt>). 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 <tt>ftape</tt> 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 <tt>ftape</tt> software. <sect1><tt>insmod</tt> says the kernel version is wrong The <tt>insmod</tt> program checks the kernel version against the version recorded in the <tt>ftape</tt> driver. This is a string in <tt>kernel-version.h</tt>, (e.g.: <tt>#define KERNEL_VERSION "1.1.72";</tt>) which is extracted from the kernel you are running when you run `<tt>make dep</tt>'. If you got the error when you tried to insert the <tt>ftape </tt> driver, remove the file `<tt>kernel-version.h</tt>', type `<tt>make dep; make</tt>' again and the <tt>kernel-version.h</tt> file should be updated. Remember that you will have to do this every time you change to another kernel version. Newer versions of <tt>insmod</tt> allows you to ``force'' insertion of a module into the kernel, even though the version string is incorrect. <sect1><tt>ftape</tt> complains that ``<tt>This tape has no 'Linux raw format'</tt>'' You get this complaint, if you haven't erased your freshly formatted tape. This is because <tt>ftape</tt> wants a ``magic header'' on the tape, to be able that it is allowed to interpret the header segment in it's own way (eg: file marks). To remove the problem, say `<tt>mt -f /dev/nftape erase</tt>' <sect1>Where can I find the <tt>tar</tt>/<tt>mt</tt>/<tt>cpio</tt>/<tt>dd</tt> binaries/sources/manpages? 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>, <tt>tsx-11.mit.edu</tt>, and <tt>sunsite.unc.edu</tt>). 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 (by 26. march 94) are: <tscreen><verb> cpio: 2.3 (cpio-2.3.tar.gz) dd: 3.9 (fileutils-3.9.tar.gz) mt: 2.3 (cpio-2.3.tar.gz) tar: 1.11.2 (tar-1.11.2.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> / <tt>libc v4.5.19</tt> / <tt>gcc v2.5.8</tt> (The <tt>rmt</tt> program does not compile out of the box, but it is not needed as it is only used for accessing the tape drive remotely). There is a patch for <tt>mt</tt> included in the <tt>ftape</tt> distribution, which makes the <tt>mt status</tt> command spew out usable information for <tt>ftape</tt> drives. <sect1>Where can I obtain the QIC standards? If you wish to help developing <tt>ftape</tt>, 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 and perhaps QIC-117. QIC-117 describes how commands are sent to the tape drive (including timing etc), so you would probably never need it. QIC-80 describes the tape layout, ECC code, standard filesystem and all such ``higher-level'' stuff. 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. <sect1>What block-size to use with <tt>tar</tt> When using compression, and in all general, it can be a benefit to specify to <tt>tar</tt>, that it should block the output into chunks. Since <tt>ftape</tt> cuts things into 29Kbyte blocks, saying `<tt>-b58</tt>' 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, <tt>ftape</tt> 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 <tt>ecc.c</tt> and <tt>ecc.h</tt> files, for an explanation of the code and a reference to a textbook on Reed-Solomon codes. <sect1><tt>ftape</tt> detects more bad sectors than DOS on QIC-3020 tapes If you look at the difference, you will notice that <tt>ftape</tt> always detects 2784 sectors more than DOS. The number that ftape reports is correct (of course <tt>:-</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: "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 behaviour 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.  <sect>Debugging the <tt>ftape</tt> driver <sect1>The kernel/<tt>ftape</tt> crashes on me when I do `...' - is that a bug? No, that is a feature <tt>;‐&rpar</tt> 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</tt>, and you can show that it is <tt>ftape</tt> that is messing things up, regard it as a Bug That Should Be Fixed. Mail the details to Bas (<tt><bas@vimec.nl></tt>) and to the tape channel. <sect1>OK, it's a bug ...ehhh... feature - How do I submit a report? First, make sure you can reproduce the problem. Spurious errors are a pain in the ass, since they are just about impossible to hunt down <tt>:-/</tt> This is a quick check list: <itemize> <item> Kernel version, and patches applied <item> <tt>ftape</tt> 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</tt> file. We may want you run try some patches out or run a different test on your system. </itemize> Increase the tracing level to 7 (just below maximum tracing) and run the offending command again. Get the tracing data from the kernel log or <tt>/proc/kmsg</tt>, depending on where you harvest your error messages. Try to look at what <tt>ftape</tt> 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</tt> 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</tt> 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</tt>"> on PCI machines above) Also, please think of the poor souls who actually pay the their Internet access (like me): avoid posting a (huge) log from the <tt>ftape</tt> 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><linux-tape@vger.rutgers.edu></tt>. You might also want to mail the bug to <tt><bas@vimec.nl></tt>. <sect1>How do I change the trace-level? You can do this two ways: either change the default trace-level (the var `<tt>tracing</tt>' in file `<tt>ftape-rw.c</tt>') and recompile or say <tscreen><verb> mt -f /dev/ftape fsr <tracing-level> </verb></tscreen> The use of the <tt>fsr</tt> command in <tt>mt</tt> is a hack, and will probably disappear or change with time. <sect1><tt>ftape</tt> keep saying `... new tape', what do I do? [You cannot do this anymore; I do not know a way of fixing it] To get rid of this, do this (blindfold): login as root and say `<tt>rmmod ftape</tt>'. <tt>ftape</tt> should choke a few times, give three segmentation violations (or so), and give up life. Check the activity LED on your floppy drive (you do have one, don't you?). If it is constantly lit, you have turned the floppy cable upside down somewhere. Check your cable between controller, tape drive and floppy drive. Usually, one (or more) of the connectors have been turned upside down, such that pin 1 in one end connects to pin 34 in the other end. (All the even-numbered pins are grounded, so you wont be able to use your floppy either). Don't worry; this cannot damage your hardware. </article>