Could you clarigy what you mean by c27 32?
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Robert Goto" <[EMAIL PROTECTED]>; "Linux Tape List"
<[EMAIL PROTECTED]>
Sent: Monday, March 27, 2000 2:30 PM
Subject: Re: ftape: Discrepancy between Iomega Ditto Tools' segments and
ftape's?
> 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]>
>
