On Mar 27, [EMAIL PROTECTED] wrote:
>
> 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.
Yes, it varies, because some of the 32 sectors that make up a segment
can be marked as bad. These sectors are simply skipped. The last
three good sectors are used as ECC, the remaining sectors are data.
> 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.
AFAIK they also count the skipped bad sectors and segments, so it may
not work if an archive is copied from one tape to another which has
different bad spots.
[...]
> 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.
/dev/rft0 was the old name, /dev/qft0 is the new name.
[...]
> 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).
Well they certainly can't claim this, since their tapes are
preformatted with a special signature in the header segment and an
encrypted(!) bad sector table (Luckily they choose a very simple
encryption ;-)
I don't know what this off by one error in the volume table is. Maybe
its just a programming error and nobody noticed since there is only
one single backup software for the Ditto 2GB.
> 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.
>
> [...]
> 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.
Maybe it's just this off by one error, maybe the Colorado software
ignores most fields in the volume table.
Jochen
