938 lines
35 KiB
HTML
938 lines
35 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Ftape-HOWTO: FAQ: "Using Ftape" related questions !</TITLE>
|
|
<LINK HREF="Ftape-HOWTO-12.html" REL=next>
|
|
<LINK HREF="Ftape-HOWTO-10.html" REL=previous>
|
|
<LINK HREF="Ftape-HOWTO.html#toc11" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Ftape-HOWTO-12.html">Next</A>
|
|
<A HREF="Ftape-HOWTO-10.html">Previous</A>
|
|
<A HREF="Ftape-HOWTO.html#toc11">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s11">11. FAQ: "Using Ftape" related questions !</A></H2>
|
|
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss11.1">11.1 How fast is Ftape ?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>You can achieve quite respectable backup and restore speeds with
|
|
<EM>Ftape</EM>: a Colorado DJ-20 and an Adaptec 1542CF controller, has
|
|
been measured at 4.25Mbyte/min sustained data transfer rate (no
|
|
compression) across a 70Mbyte tar archive, while comparing the archive
|
|
on the tape with data on an IDE disk. The speed of <EM>Ftape</EM> 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).
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss11.2">11.2 When I write to some of my tapes, they seem to spend a lot of time "shoe-shining," or repositioning instead of streaming. Is something wrong with my system?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>There has been a few reports of "shoeshining". This is when the tape just
|
|
seems to run back and forth endlessly. This has been seen on a Jumbo
|
|
250 (74407.3051@compuserve.com) and on an Iomega 250 Ditto Insider
|
|
(tom@opus.cais.com). In the latter case it has been narrowed own to
|
|
using an ELF Linux and running off a SCSI hard disk (connected to an
|
|
Adaptec 1542cf). Please contact me if you have an update to this
|
|
problem.
|
|
<P><from the Ftape-Howto>
|
|
<P>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
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ftmt -f /dev/zqft0 reten
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
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.
|
|
<P><answer from Tim Jones>
|
|
<P>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:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
find /usr/local -xdev -print | afio -o -v -f -b 10240 -c 800 /dev/qft0
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
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.
|
|
<P>Presumably other backup utilities could be modified to use a similar technique.
|
|
<P><answer by Michael Hamilton>
|
|
<P>GNU tar doesn't use buffering in this way. The commercial backup program
|
|
"bru" is able to multi-buffer using shared memory; this works only when
|
|
writing compressed archive with bru (regardless whether you use <EM>Ftape's</EM>
|
|
builtin compression)
|
|
<P>Another way to overcome the problem might be to use more dma buffers in the
|
|
<EM>Ftape kernel driver</EM> like:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/qft0 setdrvbuffer $((6*32786))
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
$((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:
|
|
<EM>Ftape's</EM> 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.
|
|
<P><answer by Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.3">11.3 Do I have to reboot to the DOS world to format tapes? </A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>Not if you are using the latest version of the <EM>Ftape drivers</EM> from the
|
|
<A HREF="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">Ftape Home Page</A>.
|
|
<P>To format a QIC-80, TR-1, TR-3, QICWide 3010 or 3020 tape, get the
|
|
latest version of <CODE>ftape</CODE> and the latest version of the
|
|
<CODE>ftape-tools</CODE> package (from the same location) and read the
|
|
documentation of the <CODE>ftformat</CODE> utility which is included in the
|
|
<CODE>ftape-tools</CODE> package.
|
|
<P>
|
|
<H4>Comment</H4>
|
|
Do not try to format Ditto 2GB tapes.
|
|
<H4>Comment</H4>
|
|
Do not try to format Ditto Max or Max Pro tapes.
|
|
<P><answers from Tim Jones and Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.4">11.4 Is it possibly to format Ditto 2GB tapes with ftape?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>It isn't possible to format <CODE>Ditto 2GB</CODE> tapes with <CODE>Ditto 2GB</CODE>
|
|
tape drive, and it isn't possible at all to re-format <CODE>Ditto 2GB</CODE>
|
|
tapes in a way that they still can be used by a <CODE>Ditto 2GB</CODE> tape
|
|
drive.
|
|
<P>This is a hardware limitation of the <CODE>Ditto 2GB</CODE> tape drive. It
|
|
can't be helped at the software level, i.e. it isn't <CODE>ftape's</CODE>
|
|
fault.
|
|
<P>
|
|
<H2><A NAME="ss11.5">11.5 Is it possibly to format Ditto Max or Max Pro tapes with ftape?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>No, the <CODE>Ditto Max</CODE> can't format tapes.
|
|
<P>This is a hardware limitation of the <CODE>Ditto Max (Pro)</CODE> tape drive. It
|
|
can't be helped at the software level, i.e. it isn't <CODE>ftape's</CODE>
|
|
fault.
|
|
<P>
|
|
<H2><A NAME="ss11.6">11.6 Ftape detects more bad sectors than DOS on QIC-3020 tapes</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>If you look at the difference, you will notice that <EM>Ftape</EM>
|
|
always detects 2784 sectors more than DOS.
|
|
<P>The number that <EM>Ftape</EM> reports is correct (of course <CODE>:-)</CODE>. 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:
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<P>This gives 12 tracks * 2 * 4 segments * 29 sectors == 2784 sectors.
|
|
<P>So <EM>Ftape</EM> choose to report the real number of sectors that cannot be
|
|
used on the tape, while DOS gives a more optimistic number giving a
|
|
better indication of tape quality. (<EM>Ftape's</EM> behavior might change in
|
|
the future to detect correct formatting and display the separate
|
|
numbers. It has rather low priority though).
|
|
<P>QIC-3010 are alike QIC-3020 tapes regarding this.
|
|
<P><from the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.7">11.7 Is it ok that I'm not hearing the tape move when I do a fsf or a bsf with mt?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>Yes. The driver merely updates an internal counter when those
|
|
commands are issues. The tape should move to the proper location on
|
|
the next read or write access to the tape drive.
|
|
<P><from the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.8">11.8 Why does my XYZ backup program complain about "Invalid argument" errors?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P><CODE>zftape</CODE> 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:
|
|
<UL>
|
|
<LI>set <EM>Ftape's</EM> block size to the block size used by the backup program. The example below works for "afio":
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/qft0 setblk 5120
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</LI>
|
|
<LI>If you don't want to use <EM>Ftape's</EM> built in compression you can also use
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/qft0 setblk 0
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
to switch <EM>Ftape</EM> to variable block size mode and be able to write the
|
|
data in arbitrary portions to the tape (BUT: the builtin compression doesn't
|
|
work with this setting). When you intend to use "KBackup" then this is the
|
|
only way to make it work together with <EM>Ftape</EM> (it _may_ work, don't know
|
|
if it does)</LI>
|
|
<LI>tell your backup program about <EM>Ftape's</EM> default block size of 10k (which
|
|
is also the default of GNU tar). For "afio" you can use the following command
|
|
line switch:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
afio -b 10k ...
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</LI>
|
|
</UL>
|
|
<P>You may want to read the section "Tape blocks" of the manual (use its
|
|
"Concept index" to directly jump to that section)
|
|
<P>When using GNU tar's builtin compression with GNU tar versions prior to
|
|
tar-1.12 one needs to run tar with the <CODE>--block-compress</CODE> switch to
|
|
<CODE>re-block</CODE> the output to the tape. Otherwise tar will compress the data
|
|
it reads, and write it in arbitrary portions to the tape.
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Example :
|
|
|
|
tar -czvf /dev/qft0 --block-compress /etc
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P><B>WARNING:</B>
|
|
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.
|
|
<P><answer by Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.9">11.9 I/O errors and FDC - some explanations.</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>When you get next messages, this could be interesting for you !
|
|
<P>
|
|
<UL>
|
|
<LI>fdc-io.c (ft_handle_perpend) - Your FDC does not support QIC-3020.</LI>
|
|
<LI>Cannot write to /dev/qft0: I/O error</LI>
|
|
</UL>
|
|
<P>The explanations:
|
|
<P>"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).
|
|
<P>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).
|
|
<P>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.
|
|
<P>
|
|
<P><answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.10">11.10 Why do I get "/dev/qft0: No such device" errors?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>I assume that the following is the problem:
|
|
The <EM>Ftape</EM> module is loaded OK into the kernel:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/usr/src/ftape-3.03b-970603# lsmod
|
|
Module Pages Used by
|
|
ftape 22 0
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
but then this happens:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
$ ftmt -f /dev/qft0 status
|
|
ftmt: /dev/qft0: No such device
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>Solution
|
|
You need to load the <EM>zftape.o</EM> module as well. With Ftape-3.* the
|
|
<EM>ftape.o</EM> module doesn't implement the VFS interface. This is done by
|
|
<EM>zftape.o</EM>.
|
|
<P><answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.11">11.11 I get "device busy" when I make multiple backups on a tape using some script.</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>The "device busy" messages can only occur while the <EM>Ftape devices</EM> 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?
|
|
<P>Yes, this will reproduce the problem, it seems:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
tar -cvvzf /dev/nqft0 --block-compress ; mt rewind
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
You can skip the "--block-compress" if using the most recent version
|
|
of GNU tar.
|
|
<P>However, this is not a bug of <EM>Ftape</EM>. 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.
|
|
<P>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.
|
|
<P>I think I have it (only for the case of tar 'cause I have the source
|
|
code.
|
|
<P>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.
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
tar - fork() - write to child tar
|
|
|
|
|
child tar - fork() - gzip (will pipe to grand child tar)
|
|
|
|
|
grand child tar - open archive.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>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().
|
|
<P>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.
|
|
<P>But this seems to be the problem: the parent tar already has exited
|
|
while its grandchild still is busy closing the archive. One hardly
|
|
will notice this problem if the close() happens fast (i.e. regular
|
|
files, block devices, also other tape devices?), but it isn't a bug in
|
|
<EM>Ftape</EM>, but either in the backup programs or in the kernel or maybe
|
|
libc exit code.
|
|
<P>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.
|
|
<P><answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.12">11.12 How do I "..." with tar?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>These are really <CODE>tar</CODE> questions: Please read the <CODE>man</CODE> page and
|
|
the <CODE>info</CODE> page. If you have not got it either, try
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
tar --help 2>&1 | less
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>If your version of <CODE>tar</CODE> is v1.11.1 or earlier, consider
|
|
upgrading to v1.11.8 - This version can call <CODE>GNU zip</CODE> directly
|
|
(i.e.: it supports the <CODE>-z</CODE> option) and has an elaborate help
|
|
included. Also, it compiles right out of the box on Linux.
|
|
<P><from the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.13">11.13 What block-size should I use with tar ?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>When using compression, and in all general, it can be a benefit to
|
|
specify to <CODE>tar</CODE>, that it should block the output into chunks.
|
|
Since <EM>Ftape</EM> cuts things into 29Kbyte blocks, saying `<CODE>-b58</CODE>'
|
|
should be optimum.
|
|
<P>"Why 29Kbyte?", I hear you cry. Well, the QIC-80 standard specifies
|
|
that all data should be protected by an Error Correcting Code (ECC)
|
|
code. The code specified in the QIC-80 standard is known as a
|
|
Reed-Solomon (R-S) code. The R-S code takes 29 data bytes and
|
|
generates 3 parity bytes. To increase the performance of the ECC
|
|
code, the parity bytes are generated across 29 1Kbyte sectors. Thus,
|
|
<EM>Ftape</EM> takes 29Kbytes of data, adds 3Kbytes of ECC parity, and
|
|
writes 32Kbytes to the tape at a time. For this reason, <EM>Ftape</EM> will
|
|
always read and write 32K byte blocks to be able to detect (and
|
|
correct) data errors.
|
|
<P>If you are curious, and wish to know more, look in the <CODE>ecc.c</CODE> and
|
|
<CODE>ecc.h</CODE> files, for an explanation of the code and a reference to a
|
|
textbook on Reed-Solomon codes.
|
|
<P><from the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.14">11.14 Where can I find the tar/mt/cpio/dd binaries - sources - manpages?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>All of these tools have been developed by the GNU project, and the
|
|
source (and man page) can be fetched from just-about any ftp site in
|
|
the world (including <CODE>ftp.funet.fi</CODE>, <CODE>tsx-11.mit.edu</CODE>, and
|
|
<CODE>sunsite.unc.edu</CODE>). In any case they can be fetched from the
|
|
official GNU home site: <CODE>prep.ai.mit.edu [18.71.0.38]:/pub/gnu</CODE>. The latest versions (as of September 12
|
|
1996) are:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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)
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>They all compile out of the box on Linux <CODE>v1.0.4</CODE> / <CODE>libc
|
|
v4.5.19</CODE> / <CODE>gcc v2.5.8</CODE>.
|
|
<P><from the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.15">11.15 If I use tapers compression, is it a bad idea to use the compression with zftape, or would it be better to not use tapers compression, and let zftape do it?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>It is not bad as such to compress data twice (which would be the case
|
|
when using tapers compression together with <EM>zftape's</EM> compression) but
|
|
it doesn't make any sense. You won't gain much further compression,
|
|
but only waste CPU cycles.
|
|
<P>Tapers compression should be quite safe, as taper compresses single
|
|
files; in contrast to <I>tar -czf ...</I> 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.
|
|
<P><Answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.16">11.16 How does zftape compression compare to say gzip -9?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P><I>gzip -9</I> is better (i.e. one gains higher compression). <EM>zftape's</EM>
|
|
compression is comparable with the Un*x <I>compress</I> program, but should
|
|
be faster, and is faster than <I>gzip</I>.
|
|
<P><Answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.17">11.17 I don't trust compression, but hear that the sftape interface is going away. What should I do?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>Use the <EM>zftape interface</EM>, but don't load the <EM>zft-compressor module</EM>.
|
|
The device then becomes <CODE>/dev/qft0</CODE>.
|
|
<P><answer from Tim Jones>
|
|
<P>
|
|
<H2><A NAME="ss11.18">11.18 Ftape says "This tape has no 'Linux raw format"</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>You get this complaint if you haven't <EM>erased</EM> your freshly
|
|
formatted tape. This is because <EM>Ftape</EM> 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
|
|
<PRE>
|
|
mt -f /dev/nftape erase
|
|
</PRE>
|
|
<P><from the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.19">11.19 Can I exchange tapes with someone using DOS?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>No. The DOS software conforms to the QIC-80 specs about the layout of
|
|
the DOS filesystem, and it should(?) be a small problem to write a
|
|
program that can read/write the DOS format. In fact, I'd bet that
|
|
creating a nice user interface would be a bigger problem.
|
|
<P><From the Ftape-Howto>
|
|
<P>
|
|
<H2><A NAME="ss11.20">11.20 How does `mt eom' work when you've started overwriting a tape in the middle?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>(EOM is "End Of recorded Media", the position right after all data
|
|
already recorded to the tape)
|
|
<P>One cannot use tape "files" like files on an ordinary file system.
|
|
<P>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.
|
|
<P>Thus, the new EOM after finishing the write process, is then after the
|
|
newly recorded data.
|
|
<P>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.
|
|
<P><from the Ftape-Howto>
|
|
<Answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.21">11.21 When I made backups before using taper, under the 2.0.29 ftape my drive didn't support fsf, under the new zftape it does, why would this be, and what exactly is fsf ?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>It probably didn't work before because you didn't use a
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/rft0 erase
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
before writing data to the cartridge. THIS ISN'T necessary any more.
|
|
<P>But, hey, what does <I>mt fsf</I>? Tape drives don't store files in the
|
|
sense that you can use
|
|
<PRE>
|
|
cp somefile /dev/my_what_ever_tape
|
|
</PRE>
|
|
|
|
or be able to mount the tape drive like you could mount a harddisk.
|
|
You can't do nothing with a tape drive but write data to it in a sequential
|
|
manner.
|
|
<P>As this is quite inconvenient, somebody invented something which is
|
|
known under the name <I>file mark</I> or <I>eof mark</I> (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).
|
|
<P>Normally, the kernel tape device drivers take care of writing file
|
|
marks when the tape device is closed, i.e.
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
tar -cf /dev/nqft0 /bin
|
|
tar -cf /dev/nqft0 /etc
|
|
mt -f /dev/nqft0 rewind
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
would result in a backup of all files under <I>/bin</I> and <I>/etc</I>. When
|
|
the first <I>tar</I> 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 <I>tar</I> process has finished, another file mark is written to the
|
|
tape cartridge at that position.
|
|
<P>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.
|
|
<P>The commands to do that are:
|
|
<DL>
|
|
<DT><B>mt fsf</B><DD><P>fast skip to the next file mark towards EOT (End Of Tape)
|
|
<DT><B>mt bsf</B><DD><P>fast skip to the next file marks towards BOT (Begin Of Tape)
|
|
</DL>
|
|
|
|
Thus, to extract the second archive in the example above, one doesn't
|
|
need to read the first archive back, but can proceed as follows:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/nqft0 rewind
|
|
mt -f /dev/nqft0 fsf
|
|
tar -xvf /dev/nqft0
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P><Answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.22">11.22 What exactly is the difference between ftape, and zftape?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>When <EM>Ftape</EM> was young there were two versions of the floppy tape
|
|
driver, one of them was called <EM>zftape</EM> because of its built-in
|
|
user-transparent on-the-fly compression. Whether such a thing is a
|
|
feature or a bug ('cause this needn't be done in kernel space) is
|
|
another question. However, the ioctl interface and file mark handling
|
|
provided by <EM>zftape</EM> was much better and had less bugs. And <EM>zftape</EM>
|
|
allows to use floppy tape cartridges with different OS. Well, you
|
|
can't exchange data, but <EM>zftape</EM> won't overwrite volumes created by
|
|
your Windoze program, and vice versa.
|
|
<P>Nowadays, <EM>Ftape</EM> is name of the entire floppy tape driver package AND
|
|
<I>ftape.o</I> is the file-name of the kernel module that implements the
|
|
low-level hardware support. <EM>zftape</EM> has ceased to exist as a separate
|
|
package, but the new <EM>Ftape</EM> versions (since ftape-3.00) contain a
|
|
<EM>zftape.o</EM> module that needs to be loaded on top of <EM>ftape.o</EM>
|
|
(i.e. you need to load BOTH modules to be able to access your floppy
|
|
tape drive) and implements the file system interface and the advanced
|
|
(?) features of the previous verions <EM>zftape</EM>.
|
|
<P><Answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.23">11.23 What is the difference between a rewinding, and non rewinding drive?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>Well, the rewinding tape devices rewind the tape to BOT (Begin Of
|
|
Tape) when the device is closed, i.e.
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
tar -cvf /dev/qft0 /bin
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
will rewind the tape cartridge when the tar job has finished. In contrast,
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
tar -cvf /dev/nqft0 /bin
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
will NOT rewind the tape cartridge and leave the tape R/W head at its
|
|
current position.
|
|
<P>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.
|
|
<P>Non-rewinding devices MUST be used when sending any of the tape motion
|
|
command to the tape drive, such as
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/nqft0 fsf
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
, because when the <I>mt</I> process finishes then the tape device is closed
|
|
which would result in rewinding the cartridge with the rewinding devices.
|
|
<P><Answer from Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.24">11.24 Can someone tell me how to use mt to rewind my TR-3 drive one record using zftape record, so I can verify it?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>Well, it depends. If the tape is still positioned inside the volume
|
|
just written, "mt bsf 1" (or equivalently "mt bsf") will backspace
|
|
just to the beginning of that volume (this is how "tar --verify"
|
|
works). If the tape is already positioned AFTER the filemark that
|
|
marks the end of the last written volume, then you need to issue
|
|
"mt bsf 2"
|
|
<P>The logic behind this is as follows:
|
|
"MTBSF count" backspaces over count file marks, stops, and then
|
|
positions on the <CODE>EOT</CODE> side of the last skipped file mark. This means,
|
|
an "mt bsf 2" will position right at the beginning of the previous
|
|
volume.
|
|
<P><answer form Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.25">11.25 By non-rewinding, they mean that it doesn't automatically rewind, correct? It doesn't mean that under no circumstances it will rewind, right? I tried using /dev/zqft0, and it instantly rewinds the tape.</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>You are right: auto-rewind means, the tape is rewound when the tape
|
|
device is closed, non-rewinding means, the tape isn't automatically
|
|
rewound when the tape device is closed (but you can, of course, use
|
|
the tape motion commands BSF/FSF etc. to position the tape head at
|
|
every position you like).
|
|
<P><answer form Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.26">11.26 What is the difference between what mt considers a record and what it considers a file?</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>A record is the minimal amount of bytes that will be accepted by the
|
|
tape in one read/write operation (except in "variable block size mode"
|
|
where it just should be the amount of data actually written in a
|
|
single write operation??).
|
|
<P>For <EM>zftape</EM> every read and write access has to be a multiple of a fixed
|
|
block size (fixed, but tunable with <CODE>MTSETBLK</CODE>). This block size is a
|
|
"tape record" (as mentioned in the GNU mt man page and defaults to
|
|
10kb for <EM>zftape</EM>.
|
|
<P>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.
|
|
<P>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 <CODE>BOT</CODE> or the file mark of the previous
|
|
tape "file". That tape "files" are the things that can be skipped with
|
|
the <CODE>MTBSF/FSF</CODE> commands.
|
|
<P><answer form Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.27">11.27 Reusing tapes with zftape without reformatting the tape.</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>We try to answer the followong questions :
|
|
<UL>
|
|
<LI>Is there a good way to erase, as in remove the data or at least the volumes
|
|
from a tape, without reformating? </LI>
|
|
<LI>Can you overwrite the last volume on a tape with making a mess out of it? </LI>
|
|
<LI>Can you overwrite the last several volumes without making a mess? </LI>
|
|
<LI>Can you delete the last volume?</LI>
|
|
</UL>
|
|
<P>If you want to "erase" an entire cartridge, then simply do:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt -f /dev/qft0 erase
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>This will erase the volume table (i.e. the "file marks").
|
|
<P>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.
|
|
<P>If you indeed need to remove some volumes on the tape then you should
|
|
use the
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
vtblc
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>program that comes with the <CODE>ftape-tools</CODE> package which can be
|
|
down-loaded from the same locations as the <CODE>ftape</CODE> kernel driver
|
|
package. Please refer to the documentation which is contained in the
|
|
<CODE>ftape-tools</CODE> package for more information.
|
|
<P>If you simply want to reuse old tapes, then it suffices to do
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mt rewind
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>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.
|
|
<P><answer by Claus Heine>
|
|
<P>
|
|
<H2><A NAME="ss11.28">11.28 This script implements a simple contents listing for the zftape package using the "MTIOCVOLINFO" ioctl.</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<P>Here is as little perl/bash script that lists the contents of a cartridge
|
|
using the <EM>zftape</EM> specific "volinfo" ioctl. Hope this shows how to
|
|
handle this kind of stuff.
|
|
<P>What it basically does is the following:
|
|
<P>
|
|
<OL>
|
|
<LI>Rewind the cartridge</LI>
|
|
<LI>Issue the volinfo command:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
claus@thales:~$ mt volinfo
|
|
file number = 1
|
|
block size = 10240
|
|
physical space used = 522.0 kilobytes
|
|
real size of volume = 520.0 kilobytes
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Parse the ouput and place the values in appropriate variables</LI>
|
|
<LI>Skip to the next volume with "mt fsf"</LI>
|
|
<LI>Exit if this gives an error (EOD), otherwise "goto 2)"</LI>
|
|
</OL>
|
|
<P><B>The Perl Script</B>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
|
|
#!/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";
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>
|
|
<P>
|
|
<P><B>The Bash Script</B>
|
|
<P>
|
|
<HR>
|
|
<PRE>
|
|
|
|
#! /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%20s%20s\n" "file number" "block size" "volume size" "tape space"
|
|
|
|
trap "rm -f /tmp/$0.$$" exit
|
|
|
|
while true
|
|
do
|
|
if ! foo=$(mt -f $TAPEDEV volinfo |cut -f 2 -d =)
|
|
then
|
|
echo $TAPEDEV doesn\'t seem to be a floppy tape device 1>&2
|
|
exit 1
|
|
fi
|
|
#
|
|
# "echo foo | read foo" will not work as the "read foo" is executed in
|
|
# another shell.
|
|
#
|
|
echo $foo > /tmp/$0.$$
|
|
read file blksz used usedunit size sizeunit < /tmp/$0.$$
|
|
if ! mt -f $TAPEDEV fsf 1 > /dev/null 2>&1
|
|
then
|
|
echo -e "\nRemaining space: $used $usedunit"
|
|
echo -e "Tape block size: $blksz"
|
|
if ! mt -f $TAPEDEV rewind
|
|
then
|
|
echo Rewind of $TAPEDEV failed 1>&2
|
|
exit 1
|
|
fi
|
|
exit 0
|
|
fi
|
|
printf "%6d %5d %20s%20s\n"\
|
|
$file $blksz "$size $sizeunit" "$used $usedunit"
|
|
done
|
|
</PRE>
|
|
<HR>
|
|
<P><answer from Claus Heine>
|
|
<P>
|
|
<HR>
|
|
<A HREF="Ftape-HOWTO-12.html">Next</A>
|
|
<A HREF="Ftape-HOWTO-10.html">Previous</A>
|
|
<A HREF="Ftape-HOWTO.html#toc11">Contents</A>
|
|
</BODY>
|
|
</HTML>
|