Robert,
On Mon, 27 Mar 2000, Robert Goto wrote:
> When I dd a tape containing 3 archives made with Iomega Tools and I dd the
> file back onto the tape the Iomega program sees it as zftape volume and not
> as an 'Iomega2GB' volume.
Quick answer:
You can use /dev/rawft0 instead of /dev/rft0 (if this
doesn't exist, find a recent MAKEDEV.ftape - one comes in
ftape-tools, or my /dev/rawft0 is c 27 32). This gives you raw access
to the tape, the first part of the tape you will read and write to is
the volume table at the start. Note that it may attempt
reading/writing the entire tape and not just your three archives, as
file marks no longer exist, so mind the count option in dd.
Longer answer:
According to the QIC standard (www.qic.org) for these tapes, the
tape is split up into 32K numbered segments, with some space used for
ECC. ftape says that this results in 29K, although I'm not sure as I
get the impression from the specs that it varies.
The first few segments contain a tape descriptor and a volume table
(with some duplicates), which describe the tape name etc, and segment
start and end numbers for each archive, along with their name, format
etc. Then each archive follows in their allocated places, in the
format specified in the volume table.
ftape (or really zftape) simulates file marks on the tape by using
the same volume table format and entering archives as vendor
specific (I believe, I've never actually looked :-), but marking the
segments' start and end points. This causes IDT to display the archive
correctly, as it can grok the QIC standard volume table, but it can't
grok the format of the actual archive (as it is tar/cpio or
something, and not actually specified anywhere - and there's no file
command in Win :=).
(You can read the volume table by running the vtblc program in the
ftape-tools package)
So, when you dd out an archive, zftape will give you the Iomega data
as it can read the volume table (being in the QIC format) but when you
write it again, zftape writes the volume table entry as 'vendor
specific' so IDT can see it, but not understand it.
/dev/rawft0 gives you access to the raw data, treating the volume
table as just more data at the beginning; so it should let you make
things such as 1:1 copies of a tape. Incidentally, does anyone know
what the difference between /dev/rft0 and /dev/qft0 is? The first is
just a symlink to the second in my system.
Off hand, I'm can't remember if /dev/rawft0 /does/ actually give you
the volume table (or if it just removes the file marks); if not, you
can use the ftmt program which comes with the ftape-tools package to
get individual ?29K segments, and if you are a programmer, can read
many segments without shoeshining with ioctls to ftape. BTW the
tape descriptor starts with the signature 0x55 0xaa 0x55 0xaa,
the volume table 0x56 0x54 0x42 0x4c ("VTBL") and an archive
0x0000000000000000 if compressed or 0xcc 0x33 0xcc 0x33 if
uncompressed, so you should be able to work out what you're getting.
One thing that I have discovered in using both /dev/qft0 and
/dev/rawft0 is that you can't just switch from one to the other -
something has a mode (normal/raw) which it remembers. ftape reports
this as the drive, but rmmoding and modprobing zftape seems to clear
this indication, however the only thing that always works is to remove
all the ftape modules, do an 'ftmt reset' and then modprobe them
again (and rebooting, of course, but who ever does that on a Linux
system?) You'll notice this if you have permission denied or invalid
operation errors (I can't remember which) and ftape's debug trace
(/var/log/messages in my case) complains about modes.
Does Iomega state that the Ditto 2GB follows QIC standards? I'm
pretty sure that they don't say anything about the Ditto Max,
although it does appear to support a somewhat dodgy QIC standard
(unless it's me). BTW I wouldn't try to dd individual archives before
checking this segment mismatch thingy first; otherwise you may get
the end of one and the start of the next or something.
> Any suggestions as to how to get this to work would be much appreciated. I
> have been able to do this with other QIC tapes, mostly Colorado backup, but
> it does not seem to work with these GB tapes.
Does Iomega state that the Ditto 2GB follows QIC standards? I'm
pretty sure that they don't say anything about the Ditto Max,
although it does appear to support a somewhat dodgy QIC standard
(unless it's me).
I don't know anything about Colorado; does ftape manage it? If so,
maybe zftape handles it differently, or perhaps it follows a
different QIC spec.
If you do end up installing ftape-tools, would you mind sending me
the output of your `vtblc --parsable` (removing any sensitive info
first, of course)? I'm interested to see if this segment mismatch
thingy I mentioned before happens on Ditto 2GB as well.
Thanks,
Robie.
(Hey, look, you're getting this email from tomorrow! Isn't global time
wonderful?)
--
Robie Basak <[EMAIL PROTECTED]>
