mirror of https://github.com/tLDP/LDP
1436 lines
51 KiB
Plaintext
1436 lines
51 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<title>The Ftape-FAQ
|
|
<author>Johan De Wit, <tt><jo@correct.nl></tt>
|
|
<date> v0.2, 07 december 1997
|
|
|
|
<abstract>
|
|
This is a very incomplete attempt to create a FAQ for the <em/Ftape
|
|
Floppy Tape Device Driver/. Any suggestions, remarks ... that could
|
|
improve this FAQ are welcome indeed.
|
|
|
|
The most recent version of this FAQ can be found at
|
|
<htmlurl url="http://www.correct.nl/~ftape/"
|
|
name="<http://www.correct.nl/~ftape/>">
|
|
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>A Word From The Maintainer Of Ftape.<p>
|
|
|
|
This is a very incomplete attempt to create a FAQ for the <em/Ftape
|
|
Floppy Tape Device Driver/.
|
|
|
|
You might encounter references to the following addresses while reading
|
|
this document:
|
|
|
|
<itemize>
|
|
<item>The maintainer of the Ftape FAQ :
|
|
|
|
<htmlurl url="mailto:jo@correct.nl"
|
|
name="Johan De Wit <jo@correct.nl>">
|
|
<item>The Ftape maintainer :
|
|
|
|
<htmlurl url="mailto:heine@math1.rwth-aachen.de"
|
|
name="Claus-Justus Heine <claus@momo.math.rwth-aachen.de>">
|
|
<item>The Ftape Home Page :
|
|
|
|
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="<http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/>">
|
|
|
|
<item>Mirrors of the Ftape Home Page :
|
|
<p>
|
|
<htmlurl url="http://www.torque.net/ftape/"
|
|
name="<http://www.torque.net/ftape/>">
|
|
<p>
|
|
Thanks to <htmlurl url="mailto:grant@torque.net"
|
|
name="Grant R. Guenther <grant@torque.net>">
|
|
<p>
|
|
<htmlurl url="http://www.info-systems.com/ftape/"
|
|
name="<http://www.info-systems.com/ftape/>">
|
|
<p>
|
|
Thanks to <htmlurl url="mailto:jc@info-systems.com"
|
|
name="Jakob Curdes <jc@info-systems.com>">
|
|
<p>
|
|
<htmlurl url="http://www.newwwave.net/~joshg/ftape/"
|
|
name="<http://www.newwave.net/~joshg/ftape/>">
|
|
<p>
|
|
Thanks to <htmlurl url="mailto:joshg@newwave.net"
|
|
name="Josh Goins <joshg@newwave.net>">
|
|
|
|
<item>The Ftape HOWTO :
|
|
|
|
<htmlurl url="http://sunsite.unc.edu/LDP/HOWTO"
|
|
name="<http://sunsite.unc.edu/LDP/HOWTO>">
|
|
|
|
<item>The Ftape Mailing List :
|
|
|
|
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
|
|
name="<linux-tape@vger.rutgers.edu>">
|
|
</itemize>
|
|
|
|
There is surely quite a lot missing. Please feel free to improve this FAQ.
|
|
The preferred way of doing this is to post to the
|
|
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
|
|
name="Ftape Mailing List">
|
|
in case you have a question that isn't answered here.
|
|
|
|
Also, if you are already reading the list regularly and have the impression
|
|
that some questions occur again and again, feel free to send that question
|
|
and possibly an answer in the format indicated below to the
|
|
<htmlurl url="mailto:jo@correct.nl"
|
|
name="maintainer">
|
|
of the <em/Ftape FAQ/ AND to
|
|
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
|
|
name="Ftape Mailing List">.
|
|
|
|
If you make FAQ related postings, then please DON'T FORGET to prepend the
|
|
word "<bf/[FAQ]/" to the subject of your posting. Please don't add the word
|
|
"FAQ" to the subject if you post something that isn't related to the FAQ.
|
|
|
|
That's all for now.
|
|
|
|
<htmlurl url="mailto:heine@math1.rwth-aachen.de"
|
|
name="Claus-Justus Heine">.
|
|
<sect>"Compiling and installing Ftape" related questions !<p>
|
|
|
|
<sect1>What Ftape version should I use?<p>
|
|
|
|
Always the latest stable version which is _supposed_ to be available from
|
|
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes"
|
|
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">
|
|
and
|
|
<htmlurl url ="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">
|
|
|
|
At time of this writing the latest stable version is <tt/ftape-4.02/.
|
|
|
|
<answer from Claus Heine>
|
|
<sect1>I'm having problems getting my XYZ drive to run under the 2.0.xx kernel with the built-in driver. How do I fix this?<p>
|
|
|
|
The default version of <em/Ftape/ included in the 2.0.xx kernel sources is
|
|
2.08 or 2.09 and is very out of date. Please update the <em/Ftape drivers/
|
|
to the latest from the
|
|
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="Ftape Home Page">.
|
|
|
|
<answer from Tim Jones>
|
|
<sect1>I'm running Linux/SMP and the system just freezes when trying to access the Ftape devices!<p>
|
|
|
|
You need to add <tt/-D__SMP__/ to the <tt/KERNEL_OPT/ variable in the
|
|
file <tt/MCONFIG/. In newer <tt/ftape/ versions you only need to
|
|
uncomment a certain line in the <tt/MCONFIG/ file.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>Why does depmod complain about "undefined symbols"?<p>
|
|
|
|
Ignore the depmod error messages. The problem is that the <em/Ftape modules/
|
|
have to be compiled without the version checksum feature (i.e.
|
|
<tt/CONFIG_MODVERSIONS/) with 2.0.* kernels. This causes no problem, even
|
|
when the modules are used with a kernel that has support for this feature;
|
|
only that <tt/depmod/ wrongly complains about undefined symbols. Ignore the
|
|
complaints of <tt/depmod/ and try to insert the modules despite of these
|
|
complaints:
|
|
<tscreen><verb>
|
|
modprobe zftape
|
|
</verb></tscreen>
|
|
If this fails, something is wrong.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>"insmod" says the kernel version is wrong<p>
|
|
|
|
The <tt/insmod/ program can check the kernel version against the
|
|
version that <em/Ftape/ was compiled for in two ways: It can directly
|
|
compare the kernel version number recorded in the <em/Ftape module/ against
|
|
the version of the running kernel, or, if both the kernel and
|
|
<em/Ftape/ is compiled with versioned symbols, compare the version of
|
|
the used kernel symbols.
|
|
|
|
If you have upgraded your version of GCC to v2.7.0 or later, you must
|
|
recompile the modules utilities with gcc v2.7.x.
|
|
|
|
Newer versions of <tt/insmod/ allows you to "force" insertion of
|
|
a module into the kernel, even though the version string is incorrect.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>"insmod" says that kernel 1.2.0 and 1.2.0 differ<p>
|
|
|
|
Did you remember to apply the <tt/ksyms.c/ patch to the kernel? If
|
|
not, read the <tt/README.linux-1.2/ file in the source distribution.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1> Trying to compile Ftape gives me the error "modversions.h: no such file or directory"<p>
|
|
|
|
The <tt/modversions.h/ file is created when the kernel is compiled
|
|
with the configuration item <tt/CONFIG_MODVERSIONS/ turned on. With
|
|
this option enabled, the file will be created during the <tt/make dep/
|
|
step.
|
|
|
|
One more handy tip is that a <tt/make mrproper/ will remove
|
|
<tt>/usr/include/linux/modversions.h</tt>. You will need to reconfig
|
|
the kernel and do a <tt/make dep/ to get the file back.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>What is this versioned symbols stuff anyway?<p>
|
|
|
|
When you say `yes' to <tt/CONFIG_MODVERSIONS/ during `<tt/make config/',
|
|
all the symbols exported by the kernel, i.e: the symbols that the
|
|
loadable modules can "see", are augmented to include a checksum
|
|
across the types of the call/return parameters. This allows
|
|
<tt/insmod/ to detect whether the definition of a variable or function
|
|
in the kernel has changed since the time when <em/Ftape/ was compiled.
|
|
|
|
This ensures a high degree of safety, such that you do not crash the
|
|
kernel because you used an outdated module with your kernel.
|
|
|
|
If you enable <tt/CONFIG_MODVERSIONS/ in the kernel, make sure you have
|
|
<verb>
|
|
-DMODVERSIONS -include /usr/include/linux/modversions.h
|
|
</verb>
|
|
uncommented in the MODULE_OPT line in the <em/Ftape/ Makefile. Conversely,
|
|
if you do not have CONFIG_MODVERSIONS enabled, make sure you have it
|
|
commented out.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>I seem to be getting sftape instead of zftape. When I run "ftmt status" command, I get output that the Ftape docs says corresponds to sftape ( /dev/qft0: Invalid argument ). Why?<p>
|
|
|
|
There are (at least) two possible sources of the problem:
|
|
<itemize>
|
|
<item>
|
|
All Ftape-3.* versions prior to 3.04 install the modules into
|
|
<tscreen><verb>
|
|
/lib/modules/misc
|
|
instead of
|
|
/lib/modules/uname -r/misc
|
|
</verb></tscreen>
|
|
As <tt/modprobe/ searches in <tt>/lib/modules/misc/</tt> last there might be
|
|
an old <tt/ftape.o/ module floating around in <tt>/lib/modules/</tt><em>
|
|
uname -r</em><tt>/misc</tt> which <tt/modprobe/ finds first (<tt/uname -r/
|
|
stands for the kernel version).
|
|
Remove the old <tt/ftape.o/ module.
|
|
<item>
|
|
Your kernel has support for <em/Ftape/ compiled in. Reconfigure
|
|
your kernel without support for <em/Ftape/ (<tt/CONFIG_FTAPE/) and
|
|
recompile and install it.
|
|
</itemize>
|
|
|
|
<answer from Claus Heins>
|
|
|
|
<sect1>My Ditto DASH/FC-20/Exabyte Accelerator card works under Microsoft Windows, but I get a drive not found type of error in /var/log/messages when trying to use it under Linux.<p>
|
|
|
|
You are probably trying to use the same IRQ and DMA settings as your on-board
|
|
FDC. This does not work in versions of <em/Ftape/ prior to 3.03b. Please
|
|
update the <em/Ftape Drivers/ to the latest from the
|
|
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="Ftape Home Page">.
|
|
|
|
<answer from Tim Jones>
|
|
|
|
<sect1>Ftape DMA transfers gives ECC errors<p>
|
|
|
|
Sadly to say there are some SVGA cards and Ethernet cards that do not
|
|
decode their addresses correct. This typically happens when the
|
|
<em/Ftape/ buffers are in the range <tt/0x1a0000/ to <tt/0x1c0000/.
|
|
Somehow, the DMA write cycles get clobbered and every other byte
|
|
written gets a bad value (<tt/0xff/). These problems are reported to
|
|
happen with both SVGA and Ethernet cards. We know of at least one
|
|
(bad?) ATI 16bit VGA card that caused this.
|
|
|
|
The easiest solution is to put the card in an 8bit slot (it is often
|
|
not enough to reconfigure the card to 8bit transfers). Moving the
|
|
<em/Ftape/ buffer away from the VGA range is only a partial
|
|
solution; All DMA buffers used in Linux can have this problem! Let us
|
|
make this one clear: This has nothing to do with the <em/Ftape/
|
|
software.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Help! I'm getting 'dmaalloc() failed' in my syslog file.<p>
|
|
|
|
You should only see this is you are trying to <tt/insmod/ the
|
|
<tt/ftape.o/ module. Try running <tt/swapout/ first. It is provided
|
|
with the standalone <em/Ftape/ source. It doesn't appear in the
|
|
<em/Ftape/ source that's provided with the kernel.
|
|
|
|
Here's an example of how you can set your rc.local file to use it.
|
|
|
|
<tscreen>
|
|
<verb>
|
|
# Install the Floppy Tape Driver
|
|
if [ -f /boot/modules/`uname -r`/misc/ftape.o ]; then
|
|
echo Installing ftape for Linux `uname -r`
|
|
swapout
|
|
insmod /boot/modules/`uname -r`/misc/ftape.o
|
|
fi
|
|
</verb>
|
|
</tscreen>
|
|
|
|
Please note that you won't have this type of problem if you compile
|
|
the <em/Ftape driver/ into the kernel.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Syslogd works overtime when running Ftape<p>
|
|
|
|
The compile-time options <tt/NO_TRACE/ and <tt/NO_TRACE_AT_ALL/ in <em/Ftape/
|
|
control the amount of system logging. Add whichever is appropriate to the
|
|
<tt/FTAPE_OPT/ line in the Makefile and recompile.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>How do I change the trace-level?<p>
|
|
|
|
There are three ways you can do this (in order of personal
|
|
preference).
|
|
|
|
While we're at it, here are the meanings of the various trace levels.
|
|
|
|
<itemize>
|
|
<item>0 Bugs
|
|
<item>1 + Errors
|
|
<item>2 + Warnings
|
|
<item>3 + Information
|
|
<item>4 + More information
|
|
<item>5 + Program flow
|
|
<item>6 + FDC/DMA info
|
|
<item>7 + Data flow
|
|
<item>8 + Everything else
|
|
</itemize>
|
|
|
|
<enum>
|
|
<item>
|
|
Using insmod to change trace-level
|
|
|
|
If you are using the modules mechanism to load the <em/Ftape/
|
|
driver, you can specify the tracing level as an option to the insmod
|
|
command.
|
|
<tscreen><verb>
|
|
/sbin/insmod ftape.o tracing=<tracing-level>
|
|
</verb></tscreen>
|
|
<item>
|
|
Using mt to change trace-level
|
|
|
|
The <em/Ftape/ driver has a hack in it that allows the <tt/fsr/ option
|
|
in <tt/mt/ to be used to set the tracing level. <tt/zftape/ does not
|
|
have this hack.
|
|
<tscreen><verb>
|
|
mt -f /dev/ftape fsr <tracing-level>
|
|
</verb></tscreen>
|
|
The use of the <tt/fsr/ command in <tt/mt/ is a <em>hack</em>,
|
|
and will probably disappear or change with time.
|
|
|
|
<item>Recompiling to change trace-level
|
|
|
|
The file <tt/tracing.c/ contains a line <tt/int tracing = 3;/.
|
|
Change the 3 to whatever is appropriate and recompile.
|
|
|
|
</enum>
|
|
|
|
<From the Ftape-Howto>
|
|
|
|
<sect1>I'm having problems with Ftape. I'm using the latest version of Ftape from the Ftape Home Page and believe that I've located a real bug. What should I do?<p>
|
|
|
|
Check the
|
|
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="Ftape Home Page">.
|
|
for an even newer version. Then check the FAQ contained in the that package
|
|
if your problem is listed there. Next, try to check if the manual that comes
|
|
with the <em/Ftape distribution/ mentions your problem.
|
|
|
|
There is no need to read the entire manual, simply check the "Concept Index"
|
|
if it contains a keyword that might be related to your problem, then jump
|
|
to the proper location in the manual.
|
|
|
|
If you are still convinced you've found a bug, then post a general question
|
|
describing the problem to the
|
|
<htmlurl url="mailto:linux-tape@vger.rutgers.edu"
|
|
name="Linux-Tape Mailing List">
|
|
, but do not attach your entire <em/Ftape/ error-log. If we've seen the
|
|
problem before, we'll let you know where the resolution effort stands. If
|
|
we haven't, the
|
|
<htmlurl url="mailto:heine@math1.rwth-aachen.de"
|
|
name="Ftape maintainer">
|
|
will most likely request that you send him the entire <em/Ftape/ error-log
|
|
(snipped from your system messages file).
|
|
|
|
<answer from Tim Jones>
|
|
|
|
<sect>"Using Ftape" related questions !<p>
|
|
|
|
<sect1>How fast is Ftape ?<p>
|
|
|
|
You can achieve quite respectable backup and restore speeds with
|
|
<em/Ftape/: a Colorado DJ-20 and an Adaptec 1542CF controller, has
|
|
been measured at 4.25Mbyte/min sustained data transfer rate (no
|
|
compression) across a 70Mbyte tar archive, while comparing the archive
|
|
on the tape with data on an IDE disk. The speed of <em/Ftape/ is
|
|
mostly dependent on the data transfer rate of your FDC: The AHA1542CF
|
|
has a ``post-1991 82077'' FDC, and it will push 1Mbit/sec at the tape
|
|
drive. If you have an FDC which can only deliver 500Kbit/sec data
|
|
rates, you will see half the transfer rate (well, roughly).
|
|
|
|
|
|
<sect1>When I write to some of my tapes, they seem to spend a lot of time "shoe-shining," or repositioning instead of streaming. Is something wrong with my system?<p>
|
|
|
|
There has been a few reports of "shoeshining". This is when the tape just
|
|
seems to run back and forth endlessly. This has been seen on a Jumbo
|
|
250 (74407.3051@compuserve.com) and on an Iomega 250 Ditto Insider
|
|
(tom@opus.cais.com). In the latter case it has been narrowed own to
|
|
using an ELF Linux and running off a SCSI hard disk (connected to an
|
|
Adaptec 1542cf). Please contact me if you have an update to this
|
|
problem.
|
|
|
|
<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
|
|
<tscreen><verb>
|
|
ftmt -f /dev/zqft0 reten
|
|
</verb></tscreen>
|
|
to retension the tape. If retensioning doesn't solve this, and it's only
|
|
happening on certain tapes, it might be wise to replace the tapes in question.
|
|
|
|
<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:
|
|
<tscreen><verb>
|
|
find /usr/local -xdev -print | afio -o -v -f -b 10240 -c 800 /dev/qft0
|
|
</verb></tscreen>
|
|
In my case I'm writing 800 x 10240 bytes per tape write, i.e. about 8MB.
|
|
haven't experimented that much with these settings - so someone might like
|
|
to establish more optimal ones.
|
|
|
|
Presumably other backup utilities could be modified to use a similar technique.
|
|
|
|
<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 <em/Ftape's/
|
|
builtin compression)
|
|
|
|
Another way to overcome the problem might be to use more dma buffers in the
|
|
<em/Ftape kernel driver/ like:
|
|
<tscreen><verb>
|
|
mt -f /dev/qft0 setdrvbuffer $((6*32786))
|
|
</verb></tscreen>
|
|
$((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/ 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.
|
|
|
|
<answer by Claus Heine>
|
|
|
|
<sect1>Do I have to reboot to the DOS world to format tapes? <p>
|
|
|
|
Not if you are using the latest version of the <em/Ftape drivers/ from the
|
|
<htmlurl url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="Ftape Home Page">.
|
|
|
|
To format a QIC-80, TR-1, TR-3, QICWide 3010 or 3020 tape, get the
|
|
latest version of <tt/ftape/ and the latest version of the
|
|
<tt/ftape-tools/ package (from the same location) and read the
|
|
documentation of the <tt/ftformat/ utility which is included in the
|
|
<tt/ftape-tools/ package.
|
|
|
|
<comment>
|
|
Do not try to format Ditto 2GB tapes.
|
|
</>
|
|
<comment>
|
|
Do not try to format Ditto Max or Max Pro tapes.
|
|
</>
|
|
|
|
<answers from Tim Jones and Claus Heine>
|
|
|
|
<sect1>Is it possibly to format Ditto 2GB tapes with ftape?<p>
|
|
|
|
It isn't possible to format <tt/Ditto 2GB/ tapes with <tt/Ditto 2GB/
|
|
tape drive, and it isn't possible at all to re-format <tt/Ditto 2GB/
|
|
tapes in a way that they still can be used by a <tt/Ditto 2GB/ tape
|
|
drive.
|
|
|
|
This is a hardware limitation of the <tt/Ditto 2GB/ tape drive. It
|
|
can't be helped at the software level, i.e. it isn't <tt/ftape's/
|
|
fault.
|
|
|
|
<sect1>Is it possibly to format Ditto Max or Max Pro tapes with ftape?<p>
|
|
|
|
No, the <tt/Ditto Max/ can't format tapes.
|
|
|
|
This is a hardware limitation of the <tt/Ditto Max (Pro)/ tape drive. It
|
|
can't be helped at the software level, i.e. it isn't <tt/ftape's/
|
|
fault.
|
|
|
|
<sect1>Ftape detects more bad sectors than DOS on QIC-3020 tapes<p>
|
|
|
|
If you look at the difference, you will notice that <em/Ftape/
|
|
always detects 2784 sectors more than DOS.
|
|
|
|
The number that <em/Ftape/ reports is correct (of course <tt/:-)/. Each
|
|
correctly formatted QIC-3020 tape has 2784 sectors at fixed positions
|
|
that are marked in the bad sector map. To quote from the specs:
|
|
|
|
<quote>
|
|
Tracks 5,7,9,11,13,15,17,19,21,23,25 and 27 within 4 segments of
|
|
either EOT or BOT are prone to increased error rates due to hole
|
|
imprints. Therefore, these regions shall be mapped as bad at format
|
|
time and entered in the bad sector map by indicating that all sectors
|
|
within the identified segments are bad.
|
|
</quote>
|
|
|
|
This gives 12 tracks * 2 * 4 segments * 29 sectors == 2784 sectors.
|
|
|
|
So <em/Ftape/ choose to report the real number of sectors that cannot be
|
|
used on the tape, while DOS gives a more optimistic number giving a
|
|
better indication of tape quality. (<em/Ftape's/ behavior might change in
|
|
the future to detect correct formatting and display the separate
|
|
numbers. It has rather low priority though).
|
|
|
|
QIC-3010 are alike QIC-3020 tapes regarding this.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Is it ok that I'm not hearing the tape move when I do a fsf or a bsf with mt?<p>
|
|
|
|
Yes. The driver merely updates an internal counter when those
|
|
commands are issues. The tape should move to the proper location on
|
|
the next read or write access to the tape drive.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Why does my XYZ backup program complain about "Invalid argument" errors?<p>
|
|
|
|
<tt/zftape/ requires the data to be written in multiples of a fixed minimal
|
|
block size. This is a very usual behavior for a tape device. There are three
|
|
ways to get rid of those errors:
|
|
<itemize>
|
|
<item>
|
|
set <em/Ftape's/ block size to the block size used by the backup program. The example below works for "afio":
|
|
<tscreen><verb>
|
|
mt -f /dev/qft0 setblk 5120
|
|
</verb></tscreen>
|
|
<item>
|
|
If you don't want to use <em/Ftape's/ built in compression you can also use
|
|
<tscreen><verb>
|
|
mt -f /dev/qft0 setblk 0
|
|
</verb></tscreen>
|
|
to switch <em/Ftape/ to variable block size mode and be able to write the
|
|
data in arbitrary portions to the tape (BUT: the builtin compression doesn't
|
|
work with this setting). When you intend to use "KBackup" then this is the
|
|
only way to make it work together with <em/Ftape/ (it _may_ work, don't know
|
|
if it does)
|
|
<item>
|
|
tell your backup program about <em/Ftape's/ default block size of 10k (which
|
|
is also the default of GNU tar). For "afio" you can use the following command
|
|
line switch:
|
|
<tscreen><verb>
|
|
afio -b 10k ...
|
|
</verb></tscreen>
|
|
</itemize>
|
|
|
|
You may want to read the section "Tape blocks" of the manual (use its
|
|
"Concept index" to directly jump to that section)
|
|
|
|
When using GNU tar's builtin compression with GNU tar versions prior to
|
|
tar-1.12 one needs to run tar with the <tt>--block-compress</tt> switch to
|
|
<tt>re-block</tt> the output to the tape. Otherwise tar will compress the data
|
|
it reads, and write it in arbitrary portions to the tape.
|
|
|
|
<tscreen>
|
|
<verb>
|
|
Example :
|
|
|
|
tar -czvf /dev/qft0 --block-compress /etc
|
|
</verb>
|
|
</tscreen>
|
|
|
|
<bf/WARNING:/
|
|
One shouldn't use tar's builtin compression with large backups as it makes the
|
|
entire data stream one huge compressed block. If such archives are corrupted
|
|
right at the beginning it will be very difficult to recover.
|
|
|
|
<answer by Claus Heine>
|
|
|
|
<sect1>I/O errors and FDC - some explanations.<p>
|
|
|
|
When you get next messages, this could be interesting for you !
|
|
|
|
<itemize>
|
|
<item>
|
|
fdc-io.c (ft_handle_perpend) - Your FDC does not support QIC-3020.
|
|
<item>
|
|
Cannot write to /dev/qft0: I/O error
|
|
</itemize>
|
|
|
|
The explanations:
|
|
|
|
"FDC" menas "Floppy Disk Controller". The
|
|
problem is that your floppy disk controller must be able to support
|
|
something that is called "perpendicular mode" to be able to read and
|
|
write QIC-3020/QIC-3010 cartridges (i.e. TR-3 cartridges). To my
|
|
knowledge all FDCs that are capable of at least 1Mbit/sec data
|
|
transfer rate also support "perpendicular mode" ("perpendicular"
|
|
refers to the direction of magnetization of the ferro-magnetic
|
|
particles on the tape).
|
|
|
|
This means that you need to purchase another FDC. Either look around
|
|
some computer stores and ask for an IO controller cards that is able
|
|
to support 2.88 Mb floppies (which imlies 1Mbit data transfer rate and
|
|
perpendicular mode).
|
|
|
|
Or get one of the so called "high speed" controllers that even support
|
|
2Mbit/sec data transfer rate. Those controllers are based on an Intel
|
|
82078 FDC. Iomega sells such a card under the name "Ditto Dash". I
|
|
think Exabyte sells their 2Mbit controllers separately, too, whereas
|
|
Seagate ships its TR-3 drives (i.e. the TST-3200) together with such a
|
|
controller.
|
|
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>Why do I get "/dev/qft0: No such device" errors?<p>
|
|
|
|
I assume that the following is the problem:
|
|
The <em/Ftape/ module is loaded OK into the kernel:
|
|
<tscreen><verb>
|
|
/usr/src/ftape-3.03b-970603# lsmod
|
|
Module Pages Used by
|
|
ftape 22 0
|
|
</verb></tscreen>
|
|
but then this happens:
|
|
<tscreen><verb>
|
|
$ ftmt -f /dev/qft0 status
|
|
ftmt: /dev/qft0: No such device
|
|
</verb></tscreen>
|
|
|
|
Solution
|
|
You need to load the <em/zftape.o/ module as well. With Ftape-3.* the
|
|
<em/ftape.o/ module doesn't implement the VFS interface. This is done by
|
|
<em/zftape.o/.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>I get "device busy" when I make multiple backups on a tape using some script.<p>
|
|
|
|
The "device busy" messages can only occur while the <em/Ftape devices/ are
|
|
still held open by some program. As soon as the close() system call has
|
|
completed the busy flag is cleared. May be "bru" or some other program has
|
|
still forked off a child that dies delayed?
|
|
|
|
Yes, this will reproduce the problem, it seems:
|
|
<tscreen><verb>
|
|
tar -cvvzf /dev/nqft0 --block-compress ; mt rewind
|
|
</verb></tscreen>
|
|
You can skip the "--block-compress" if using the most recent version
|
|
of GNU tar.
|
|
|
|
However, this is not a bug of <em/Ftape/. It seems that the parent tar
|
|
process exits before its child has closed the tape device. I know,
|
|
however, from hacking the tar code ages ago, that tar properly waits
|
|
for its parent to die.
|
|
|
|
However, the busy message simply means that the "busy" variable is
|
|
still held at 1 (zftape/zftape-init.c). And this simply means that
|
|
there still is a process hanging around that holds the tape device
|
|
open.
|
|
|
|
I think I have it (only for the case of tar 'cause I have the source
|
|
code.
|
|
|
|
If on uses tar with compression, then it forks a child which will
|
|
become the compressor bei execing "gzip" or whatever. Before the call
|
|
to execlp() the child will fork off a grand child of its parent
|
|
tar. That grandchild will do the actual tape I/O.
|
|
<tscreen><verb>
|
|
tar - fork() - write to child tar
|
|
|
|
|
child tar - fork() - gzip (will pipe to grand child tar)
|
|
|
|
|
grand child tar - open archive.
|
|
</verb></tscreen>
|
|
|
|
Now, parent tar only waits for its child to die. gzip surely doesn't
|
|
wait for the grand child as the gzip is a result of an execlp().
|
|
|
|
What I don't know is whether the grand child should be implicitly
|
|
waited for by the parent tar, or if the wait() function also waits for
|
|
grand childs.
|
|
|
|
But this seems to be the problem: the parent tar already has exited
|
|
while its grandchild still is busy closing the archive. One hardly
|
|
will notice this problem if the close() happens fast (i.e. regular
|
|
files, block devices, also other tape devices?), but it isn't a bug in
|
|
<em/Ftape/, but either in the backup programs or in the kernel or maybe
|
|
libc exit code.
|
|
|
|
Don't know if the considerations above also apply to bru. If there is
|
|
no grandchild and the parent process properly waits for its childs
|
|
then there shouldn't be a problem.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>How do I "..." with tar?<p>
|
|
|
|
These are really <tt/tar/ questions: Please read the <tt/man/ page and
|
|
the <tt/info/ page. If you have not got it either, try
|
|
<tscreen><verb>
|
|
tar --help 2>&1 | less
|
|
</verb></tscreen>
|
|
|
|
If your version of <tt/tar/ is v1.11.1 or earlier, consider
|
|
upgrading to v1.11.8 - This version can call <tt/GNU zip/ directly
|
|
(i.e.: it supports the <tt/-z/ option) and has an elaborate help
|
|
included. Also, it compiles right out of the box on Linux.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>What block-size should I use with tar ?<p>
|
|
|
|
When using compression, and in all general, it can be a benefit to
|
|
specify to <tt/tar/, that it should block the output into chunks.
|
|
Since <em/Ftape/ cuts things into 29Kbyte blocks, saying `<tt/-b58/'
|
|
should be optimum.
|
|
|
|
"Why 29Kbyte?", I hear you cry. Well, the QIC-80 standard specifies
|
|
that all data should be protected by an Error Correcting Code (ECC)
|
|
code. The code specified in the QIC-80 standard is known as a
|
|
Reed-Solomon (R-S) code. The R-S code takes 29 data bytes and
|
|
generates 3 parity bytes. To increase the performance of the ECC
|
|
code, the parity bytes are generated across 29 1Kbyte sectors. Thus,
|
|
<em/Ftape/ takes 29Kbytes of data, adds 3Kbytes of ECC parity, and
|
|
writes 32Kbytes to the tape at a time. For this reason, <em/Ftape/ will
|
|
always read and write 32K byte blocks to be able to detect (and
|
|
correct) data errors.
|
|
|
|
If you are curious, and wish to know more, look in the <tt/ecc.c/ and
|
|
<tt/ecc.h/ files, for an explanation of the code and a reference to a
|
|
textbook on Reed-Solomon codes.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Where can I find the tar/mt/cpio/dd binaries - sources - manpages?<p>
|
|
|
|
All of these tools have been developed by the GNU project, and the
|
|
source (and man page) can be fetched from just-about any ftp site in
|
|
the world (including <tt/ftp.funet.fi/, <tt/tsx-11.mit.edu/, and
|
|
<tt/sunsite.unc.edu/). In any case they can be fetched from the
|
|
official GNU home site: <tt>prep.ai.mit.edu
|
|
[18.71.0.38]:/pub/gnu</tt>. The latest versions (as of September 12
|
|
1996) are:
|
|
|
|
<tscreen><verb>
|
|
cpio: 2.4.2 (cpio-2.4.2.tar.gz)
|
|
dd: 3.13 (fileutils-3.13.tar.gz)
|
|
mt: 2.4.2 (cpio-2.4.2.tar.gz)
|
|
tar: 1.11.8 (tar-1.11.8.tar.gz)
|
|
gzip: 1.2.4 (gzip-1.2.4.tar.gz)
|
|
</verb></tscreen>
|
|
|
|
They all compile out of the box on Linux <tt/v1.0.4/ / <tt/libc
|
|
v4.5.19/ / <tt/gcc v2.5.8/.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>If I use tapers compression, is it a bad idea to use the compression with zftape, or would it be better to not use tapers compression, and let zftape do it?<p>
|
|
|
|
It is not bad as such to compress data twice (which would be the case
|
|
when using tapers compression together with <em/zftape's/ compression) but
|
|
it doesn't make any sense. You won't gain much further compression,
|
|
but only waste CPU cycles.
|
|
|
|
Tapers compression should be quite safe, as taper compresses single
|
|
files; in contrast to <it/tar -czf .../ which makes the entire data
|
|
stream a large compressed block of data, which is really a bad thing
|
|
with serious backups as a single bad byte at the beginning of the
|
|
archive can make the entire archive unusable, well, it will be at
|
|
least quite difficult to recover.
|
|
|
|
<Answer from Claus Heine>
|
|
|
|
<sect1>How does zftape compression compare to say gzip -9?<p>
|
|
|
|
<it/gzip -9/ is better (i.e. one gains higher compression). <em/zftape's/
|
|
compression is comparable with the Un*x <it/compress/ program, but should
|
|
be faster, and is faster than <it/gzip/.
|
|
|
|
<Answer from Claus Heine>
|
|
|
|
<sect1>I don't trust compression, but hear that the sftape interface is going away. What should I do?<p>
|
|
|
|
Use the <em/zftape interface/, but don't load the <em/zft-compressor module/.
|
|
The device then becomes <tt>/dev/qft0</tt>.
|
|
|
|
<answer from Tim Jones>
|
|
|
|
<sect1>Ftape says "This tape has no 'Linux raw format"<p>
|
|
|
|
You get this complaint if you haven't <em>erased</em> your freshly
|
|
formatted tape. This is because <em/Ftape/ expect a "magic header"
|
|
on the tape, to be able that it is allowed to interpret the header
|
|
segment in its own way (eg: file marks). To remove the problem, say
|
|
<verb>
|
|
mt -f /dev/nftape erase
|
|
</verb>
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Can I exchange tapes with someone using DOS?<p>
|
|
|
|
No. The DOS software conforms to the QIC-80 specs about the layout of
|
|
the DOS filesystem, and it should(?) be a small problem to write a
|
|
program that can read/write the DOS format. In fact, I'd bet that
|
|
creating a nice user interface would be a bigger problem.
|
|
|
|
<From the Ftape-Howto>
|
|
|
|
<sect1>How does `mt eom' work when you've started overwriting a tape in the middle?<p>
|
|
|
|
(EOM is "End Of recorded Media", the position right after all data
|
|
already recorded to the tape)
|
|
|
|
One cannot use tape "files" like files on an ordinary file system.
|
|
|
|
In principle, a tape doesn't allow anything but appending new data at
|
|
EOM. However, if one positiones just in the middle of the already
|
|
recorded data AND starts writing, then the driver first deletes all
|
|
following files (thus moving the EOM to the actual position) and then
|
|
starts writing.
|
|
|
|
Thus, the new EOM after finishing the write process, is then after the
|
|
newly recorded data.
|
|
|
|
One of the consequences of the above is, of course, that writing to
|
|
the tape in the middle of the already recorded area, is destructive in
|
|
the sense, that it not only overwrites the "file" the tape is
|
|
positioned at, but also deletes all following files.
|
|
|
|
<from the Ftape-Howto>
|
|
<Answer from Claus Heine>
|
|
|
|
<sect1>When I made backups before using taper, under the 2.0.29 ftape my drive didn't support fsf, under the new zftape it does, why would this be, and what exactly is fsf ?<p>
|
|
|
|
It probably didn't work before because you didn't use a
|
|
<tscreen><verb>
|
|
mt -f /dev/rft0 erase
|
|
</verb></tscreen>
|
|
before writing data to the cartridge. THIS ISN'T necessary any more.
|
|
|
|
But, hey, what does <it/mt fsf/? Tape drives don't store files in the
|
|
sense that you can use <verb>cp somefile /dev/my_what_ever_tape</verb>
|
|
or be able to mount the tape drive like you could mount a harddisk.
|
|
You can't do nothing with a tape drive but write data to it in a sequential
|
|
manner.
|
|
|
|
As this is quite inconvenient, somebody invented something which is
|
|
known under the name <it/file mark/ or <it/eof mark/ (eof == End Of
|
|
File). Those marks don't separate files that have been backed up to
|
|
the tape device, but only separate blocks of data (whatever data that
|
|
might be).
|
|
|
|
Normally, the kernel tape device drivers take care of writing file
|
|
marks when the tape device is closed, i.e.
|
|
<tscreen><verb>
|
|
tar -cf /dev/nqft0 /bin
|
|
tar -cf /dev/nqft0 /etc
|
|
mt -f /dev/nqft0 rewind
|
|
</verb></tscreen>
|
|
would result in a backup of all files under <it>/bin</it> and <it>/etc</it>. When
|
|
the first <it/tar/ finishes, the kernel driver will take care of writing
|
|
a file mark to the tape at the current tape position, and when the
|
|
second <it/tar/ process has finished, another file mark is written to the
|
|
tape cartridge at that position.
|
|
|
|
Now, the sense of those file marks is, that it is possible to skip
|
|
between different archives on the tape more quickly than would be
|
|
possible with reading the data back.
|
|
|
|
The commands to do that are:
|
|
<descrip>
|
|
<tag/mt fsf/fast skip to the next file mark towards EOT (End Of Tape)
|
|
<tag/mt bsf/fast skip to the next file marks towards BOT (Begin Of Tape)
|
|
</descrip>
|
|
Thus, to extract the second archive in the example above, one doesn't
|
|
need to read the first archive back, but can proceed as follows:
|
|
<tscreen><verb>
|
|
mt -f /dev/nqft0 rewind
|
|
mt -f /dev/nqft0 fsf
|
|
tar -xvf /dev/nqft0
|
|
</verb></tscreen>
|
|
|
|
<Answer from Claus Heine>
|
|
|
|
<sect1>What exactly is the difference between ftape, and zftape?<p>
|
|
|
|
When <em/Ftape/ was young there were two versions of the floppy tape
|
|
driver, one of them was called <em/zftape/ because of its built-in
|
|
user-transparent on-the-fly compression. Whether such a thing is a
|
|
feature or a bug ('cause this needn't be done in kernel space) is
|
|
another question. However, the ioctl interface and file mark handling
|
|
provided by <em/zftape/ was much better and had less bugs. And <em/zftape/
|
|
allows to use floppy tape cartridges with different OS. Well, you
|
|
can't exchange data, but <em/zftape/ won't overwrite volumes created by
|
|
your Windoze program, and vice versa.
|
|
|
|
Nowadays, <em/Ftape/ is name of the entire floppy tape driver package AND
|
|
<it/ftape.o/ is the file-name of the kernel module that implements the
|
|
low-level hardware support. <em/zftape/ has ceased to exist as a separate
|
|
package, but the new <em/Ftape/ versions (since ftape-3.00) contain a
|
|
<em/zftape.o/ module that needs to be loaded on top of <em/ftape.o/
|
|
(i.e. you need to load BOTH modules to be able to access your floppy
|
|
tape drive) and implements the file system interface and the advanced
|
|
(?) features of the previous verions <em/zftape/.
|
|
|
|
<Answer from Claus Heine>
|
|
|
|
<sect1>What is the difference between a rewinding, and non rewinding drive?<p>
|
|
|
|
Well, the rewinding tape devices rewind the tape to BOT (Begin Of
|
|
Tape) when the device is closed, i.e.
|
|
<tscreen><verb>
|
|
tar -cvf /dev/qft0 /bin
|
|
</verb></tscreen>
|
|
will rewind the tape cartridge when the tar job has finished. In contrast,
|
|
<tscreen><verb>
|
|
tar -cvf /dev/nqft0 /bin
|
|
</verb></tscreen>
|
|
will NOT rewind the tape cartridge and leave the tape R/W head at its
|
|
current position.
|
|
|
|
Rewinding devices should be used when performing a single backup,
|
|
non-rewinding devices can be useful when doing multiple backups as one
|
|
doesn't need to space to EOM (End Of recorded Media) before appending
|
|
another archive.
|
|
|
|
Non-rewinding devices MUST be used when sending any of the tape motion
|
|
command to the tape drive, such as
|
|
<tscreen><verb>
|
|
mt -f /dev/nqft0 fsf
|
|
</verb></tscreen>
|
|
, because when the <it/mt/ process finishes then the tape device is closed
|
|
which would result in rewinding the cartridge with the rewinding devices.
|
|
|
|
<Answer from Claus Heine>
|
|
|
|
<sect1>Can someone tell me how to use mt to rewind my TR-3 drive one record using zftape record, so I can verify it?<p>
|
|
|
|
Well, it depends. If the tape is still positioned inside the volume
|
|
just written, "mt bsf 1" (or equivalently "mt bsf") will backspace
|
|
just to the beginning of that volume (this is how "tar --verify"
|
|
works). If the tape is already positioned AFTER the filemark that
|
|
marks the end of the last written volume, then you need to issue
|
|
"mt bsf 2"
|
|
|
|
The logic behind this is as follows:
|
|
"MTBSF count" backspaces over count file marks, stops, and then
|
|
positions on the <tt/EOT/ side of the last skipped file mark. This means,
|
|
an "mt bsf 2" will position right at the beginning of the previous
|
|
volume.
|
|
|
|
<answer form Claus Heine>
|
|
|
|
<sect1>By non-rewinding, they mean that it doesn't automatically rewind, correct? It doesn't mean that under no circumstances it will rewind, right? I tried using /dev/zqft0, and it instantly rewinds the tape.<P>
|
|
|
|
You are right: auto-rewind means, the tape is rewound when the tape
|
|
device is closed, non-rewinding means, the tape isn't automatically
|
|
rewound when the tape device is closed (but you can, of course, use
|
|
the tape motion commands BSF/FSF etc. to position the tape head at
|
|
every position you like).
|
|
|
|
<answer form Claus Heine>
|
|
|
|
<sect1>What is the difference between what mt considers a record and what it considers a file?<p>
|
|
|
|
A record is the minimal amount of bytes that will be accepted by the
|
|
tape in one read/write operation (except in "variable block size mode"
|
|
where it just should be the amount of data actually written in a
|
|
single write operation??).
|
|
|
|
For <em/zftape/ every read and write access has to be a multiple of a fixed
|
|
block size (fixed, but tunable with <tt/MTSETBLK/). This block size is a
|
|
"tape record" (as mentioned in the GNU mt man page and defaults to
|
|
10kb for <em/zftape/.
|
|
|
|
A "file" (in the sense of the mt man page) is a, well, misleading
|
|
terminus. What is meant is an area of the tape between two file
|
|
marks. This is not a file like a file on the file system, in the sense
|
|
that it could have a name, file access modes, could be moved or copied
|
|
with cp, mv, rm etc.
|
|
|
|
Instead, It simply is the area of the tape that was recorded in one
|
|
backup session, its end is marked by a tape file mark, and its
|
|
beginning is delimited by either <tt/BOT/ or the file mark of the previous
|
|
tape "file". That tape "files" are the things that can be skipped with
|
|
the <tt>MTBSF/FSF</tt> commands.
|
|
|
|
<answer form Claus Heine>
|
|
|
|
<sect1>Reusing tapes with zftape without reformatting the tape.<p>
|
|
|
|
We try to answer the followong questions :
|
|
<itemize>
|
|
<item>
|
|
Is there a good way to erase, as in remove the data or at least the volumes
|
|
from a tape, without reformating?
|
|
<item>
|
|
Can you overwrite the last volume on a tape with making a mess out of it?
|
|
<item>
|
|
Can you overwrite the last several volumes without making a mess?
|
|
<item>
|
|
Can you delete the last volume?
|
|
</itemize>
|
|
|
|
If you want to "erase" an entire cartridge, then simply do:
|
|
|
|
<tscreen><verb>
|
|
mt -f /dev/qft0 erase
|
|
</verb></tscreen>
|
|
|
|
This will erase the volume table (i.e. the "file marks").
|
|
|
|
Pre-ftape-3.x releases of zftape and ftape used to allow overwriting
|
|
of already existing volumes on a cartridge. I have removed this
|
|
feature as it was reported that it already has caused data-loss with
|
|
some backup programs.
|
|
|
|
If you indeed need to remove some volumes on the tape then you should
|
|
use the
|
|
|
|
<tscreen><verb>
|
|
vtblc
|
|
</verb></tscreen>
|
|
|
|
program that comes with the <tt/ftape-tools/ package which can be
|
|
down-loaded from the same locations as the <tt/ftape/ kernel driver
|
|
package. Please refer to the documentation which is contained in the
|
|
<tt/ftape-tools/ package for more information.
|
|
|
|
If you simply want to reuse old tapes, then it suffices to do
|
|
|
|
<tscreen><verb>
|
|
mt rewind
|
|
</verb></tscreen>
|
|
|
|
If the tape is at BOT (Begin Of Tape) then every write access to the
|
|
tape will silently erase all file marks and overwrite the data already
|
|
existing on the tape.
|
|
|
|
<answer by Claus Heine>
|
|
|
|
<sect1>This script implements a simple contents listing for the zftape package using the "MTIOCVOLINFO" ioctl.<p>
|
|
|
|
Here is as little perl/bash script that lists the contents of a cartridge
|
|
using the <em/zftape/ specific "volinfo" ioctl. Hope this shows how to
|
|
handle this kind of stuff.
|
|
|
|
What it basically does is the following:
|
|
|
|
<enum>
|
|
<item>
|
|
Rewind the cartridge
|
|
<item>
|
|
Issue the volinfo command:
|
|
<tscreen><verb>
|
|
claus@thales:~$ mt volinfo
|
|
file number = 1
|
|
block size = 10240
|
|
physical space used = 522.0 kilobytes
|
|
real size of volume = 520.0 kilobytes
|
|
</verb></tscreen>
|
|
Parse the ouput and place the values in appropriate variables
|
|
<item>
|
|
Skip to the next volume with "mt fsf"
|
|
<item>
|
|
Exit if this gives an error (EOD), otherwise "goto 2)"
|
|
</enum>
|
|
|
|
<bf/The Perl Script/
|
|
|
|
<tscreen>
|
|
<verb>
|
|
|
|
#!/usr/bin/perl
|
|
#
|
|
# Copyright (C) 1997 Claus-Justus Heine
|
|
#
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 2, or (at your option)
|
|
# any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program; see the file COPYING. If not, write to
|
|
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
#
|
|
# This script implements a simple contents listing for the zftape
|
|
# package using the MTIOCVOLINFO ioctl.
|
|
#
|
|
|
|
$version = <<EOT;
|
|
listtape-1.0 -- a perl script to list the contents of a floppy tape cartridge
|
|
under Linux using the zftape driver
|
|
|
|
RCS \$Revision$
|
|
RCS \$Date$
|
|
EOT
|
|
|
|
$tapedev = "/dev/tape";
|
|
$usage = <<EOT;
|
|
Usage: listtape [options ...]
|
|
|
|
Mandatory or optional arguments to long options are mandatory or optional
|
|
for short options too.
|
|
|
|
-f, --file=FILE Tape device to use. Default is "/dev/tape".
|
|
-h, --help Print this help.
|
|
-? Same as '-h'.
|
|
--usage Same as '-h'.
|
|
-V, --version Print version information.
|
|
|
|
Author: Claus-Justus Heine <claus\@momo.math.rwth-aachen.de>
|
|
EOT
|
|
|
|
while ($ARGV[0] =~ /^-/) {
|
|
$_ = 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";
|
|
}
|
|
|
|
</verb></tscreen>
|
|
|
|
|
|
|
|
<bf/The Bash Script/
|
|
|
|
<code>
|
|
|
|
#! /bin/bash
|
|
#
|
|
# Copyright (C) 1997 Claus-Justus Heine
|
|
#
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 2, or (at your option)
|
|
# any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program; see the file COPYING. If not, write to
|
|
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
#
|
|
# This script implements a simple contents listing for the zftape
|
|
# package using the MTIOCVOLINFO ioctl.
|
|
#
|
|
|
|
#
|
|
# insert better option parsing here
|
|
#
|
|
TAPEDEV=${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
|
|
|
|
</code>
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect>"Tape and Drivers" related questions !<p>
|
|
|
|
<sect1>What are good makers of Travan tapes?<p>
|
|
|
|
I was the UNIX Product Manager at Archive Corp (Prior to the Conner/Seagate
|
|
mess) and we performed extensive tests of tape media for compatibility
|
|
certification, including retentivity, flaking and length consistancy. Based
|
|
on the results of the tests, we selected the best of these certified
|
|
manufacturers' products to private label as our own media. Here is the
|
|
order in which we selected vendors up through 1995 (when I lost contact
|
|
with the ATI group):
|
|
|
|
<descrip>
|
|
<tag/QIC/
|
|
<enum>
|
|
<item> 3M (now known as Imation)
|
|
<item> QMaxell/Sony (tie)
|
|
<item> (BTW - Iomega uses Sony private-labelled media)
|
|
</enum>
|
|
<tag/4MM/
|
|
<enum>
|
|
<item> Fuji
|
|
<item> Maxell/Sony (tie - is this a trend?)
|
|
</enum>
|
|
<tag/8MM/
|
|
<enum>
|
|
<item> Fuji/Exabyte - which we believed to be OEM'd Fuji (tie - so much for trend!)
|
|
<item> Sony
|
|
<item> Maxell
|
|
</enum>
|
|
<tag/DLT/
|
|
<enum>
|
|
<item> Maxell
|
|
<item> Sony
|
|
</enum>
|
|
</descrip>
|
|
|
|
Otherwise, we had entries in our search from other vendors which were
|
|
generally a private-labelled version of one of the major labels above. The
|
|
exceptions were Verbatim and DIC. Both of these manufacturer's media had
|
|
fall-out rates and length discrepancies that were so high that we would not
|
|
certify them and even warned customers about them indicating that we could
|
|
not offer any sort of guarantee that they would get a good backup using the
|
|
media from these manufacturers.
|
|
|
|
In addition, since coming to EST, I've found that Verbatim media is still
|
|
not worth the money saved in purchasing it. We have 11 of their TR-Extra
|
|
and QIC-Extra (QICXL) tapes that were useless after fewer than 20 passes each.
|
|
|
|
While this is my personal opinion, it is based on over 9 years of experience
|
|
with this very question, I strongly recommend Imation/3M media for QIC/Travan
|
|
user, Fuji media 4MM users, Exabyte/Fuji for 8MM and DEC labelled media
|
|
for DLT users.
|
|
|
|
<answer from Tim Jones>
|
|
|
|
<sect1>Where can I obtain the QIC standards?<p>
|
|
|
|
If you wish to help developing <em/Ftape/, or add some utility
|
|
(e.g. a tape formatting program), you will need that appropriate QIC
|
|
standards. The standard(s) to get is: QIC-80, -117, -3010, and 3020.
|
|
QIC-117 describes how commands are sent to the tape drive (including
|
|
timing etc), so you would probably never need it. QIC-80/3010/3020
|
|
describes higher level part, such as tape layout, ECC code, standard
|
|
filesystem. You can get the QIC standards from the following address:
|
|
|
|
<tscreen><verb>
|
|
Quarter Inch Cartridge Drive Standards, Inc.
|
|
311 East Carrillo Street
|
|
Santa Barbara, California 93101
|
|
Phone: (805) 963-3853
|
|
Fax: (805) 962-1541
|
|
</verb></tscreen>
|
|
|
|
Note: They are registered as `Freeman Associates, Inc' in the phone
|
|
book.
|
|
|
|
<from the Ftape-Howto>
|
|
|
|
<sect1>Is the Iomega Ditto 2GB drive supported?<p>
|
|
|
|
Yes, if you are using version <tt/ftape-3.x/ or later of the <em/Ftape
|
|
drivers/ from the <htmlurl
|
|
url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="Ftape Home Page"> or from
|
|
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes"
|
|
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">.
|
|
|
|
<answer from Tim Jones>
|
|
|
|
As the Ditto 2GB is a Tr-3 tape (though it can only store 1GB instead of the
|
|
1.6GB you get with a regular Tr-3 drive) you need an FDC (FDC means: Floppy
|
|
Disk Controller) that is capable of at 1Mbit/sec transfer rate. You don't need
|
|
to worry about this if you have an accellerator card (i.e. the Ditto Dash
|
|
controller). Otherwise try to purchase an FDC that claims to be capable of
|
|
driving 2.88Mb floppies because this implies that the FDC is capable of 1Mbit
|
|
transfer rate.
|
|
|
|
<em/Ftape/ prints the maximum data rate of the FDC to the kernel log
|
|
files like this:
|
|
<verb>
|
|
ftape-ctl.c (ftape_init_drive) - Highest FDC supported data rate: 500 Kbps.
|
|
</verb>
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>Is the Iomega Ditto Max drive supported?<p>
|
|
|
|
Yes, if you are using version <tt/ftape-4.02/ or later of the
|
|
<em/Ftape drivers/ from the <htmlurl
|
|
url="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/"
|
|
name="Ftape Home Page"> or from <htmlurl
|
|
url="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes"
|
|
name="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>Is the Iomega Ditto Max Pro drive supported?<p>
|
|
|
|
Yes. But if you want to use the 5GB (10GB with compression) cartridges
|
|
you don't need it. With <tt/ftape/ there doesn't seem to be any
|
|
difference between the <tt/Ditto Max/ and the <tt/Ditto Max Pro/.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect>Miscellaneous !<p>
|
|
|
|
<sect1>How to subscribe to the Ftape Mailing List?<p>
|
|
|
|
You can subscribe to that list by sending mail to
|
|
<tscreen><verb>
|
|
majordomo@vger.rutgers.edu
|
|
</verb></tscreen>
|
|
with the single line
|
|
<tscreen><verb>
|
|
subscribe linux-tape
|
|
</verb></tscreen>
|
|
in its body. Please store the answer you get from majordomo in a safe place
|
|
because it contains instructions how to <tt/UNSUBSCRIBE/ from the mailing list.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>How to un-subscribe from the Ftape Mailing List?<p>
|
|
|
|
Send mail to
|
|
<tscreen><verb>
|
|
majordomo@vger.rutgers.edu
|
|
</verb></tscreen>
|
|
with the single line
|
|
<tscreen><verb>
|
|
unsubscribe linux-tape MY@EMAIL.ADDRESS
|
|
</verb></tscreen>
|
|
where <tt/MY@EMAIL.ADDRESS/ has to be replaced by the email
|
|
address that you used when subscribing to the list. Note that you must
|
|
have received an email with instructions how to unsubscribe from the
|
|
mailing list at the time you subscribed to it.
|
|
|
|
<answer from Claus Heine>
|
|
|
|
<sect1>Links to related information.<p>
|
|
|
|
|
|
<htmlurl url="http://www.uwsg.indiana.edu/usail/library/backups.html"
|
|
name="<http://www.uwsg.indiana.edu/usai/library/backups.html>">
|
|
|
|
More links wanted !!!
|
|
|
|
|
|
</article>
|