[EMAIL PROTECTED] wrote:
> Could you clarigy what you mean by c27 32?
To create the device /dev/rawft0, you can either run the script MAKEDEV.ftape which
comes with ftape-tools (same place as the main ftape driver), or you can type (as root)
mknod /dev/rawft0 c 27 32
to create the device. The script does rawft0-3 and other stuff, so it's more
'correct', but the mknod will suffice for you if you just need that particular device.
Robie.
> ----- 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]>
> >
>
>
>
>
