Hi Robie,
> Unfortunately, Iomega are hiding behind an NDA, and Tecmar have been
> very willing to help, but they contract the software to Vertitas who
> certainly won't be.
That's why they do not hide; Veritas does it for them :-)
> IMHO this is a flaw in the specs, although it can be worked around.
> I've been compiling a list of "features"; I'm going to suggest a
> revision h, where the segment number of the directory section will eat
> up another four bytes off the vendor extension field.
Well, maybe I'm a little bit to naive, but I had the impression that
the specs are pretty clear w.r.t. this point. "Rounding up to segment
boundary" means "take the smallest number of segments necessary to
hold the data".
> You're absolutely right; the specifications themselves allow for many
> variations; I've _finally_ come up with some almost-neat looking code
> which handles segment-spanning, non-segment-spanning and uncompressed
> volumes gracefully and transparantely, but it did take a lot of
> head-scratching :-)
I know what you mean. The compression frame stuff is a little bit
complicated. I had implemented it for ftape-3.x in kernel land,
although with another compression algorithm (lzrw3).
> And only _then_ do I realize that compression frame sizes are limited
> to 64K even on segment spanning volumes :-( Makes me wonder what the
> point of non-segment spanning volumes is, anyway.
Well, but this isn't too bad. Ok, larger frames allow better
compression -- but only at the cost of loosing more data when the
backup tape has read-errors during restore.
Backup frames can be restored independently from each other. And they
should not bee too large for data-security reasons.
> I'm beginning to think that doing the writing support first might have
> been easier, as I only have to write it one way; what put me off was
> the compression algae-rhythm :-)
>
> Only now, when half the reading code's in place, does it occur to me
> that I don't need to do compression :-(
Yes, but it is a nice feature, if coded in user land.
> Two items of help I can think of:
>
> 1. A name! I still haven't thought of a decent name for this program
> :-)
The most difficult problem in mathematical proofs is to invent new
names for the indices ... :-)
> 2. I'll need _lots_ of testing, as multiple software writes it in
> multiple ways. This, of course, will have to wait until the code
> actually compiles and does something :-)
Maybe first support reading back for one product, and then add the
others. If you try to support all other backup programs at once, then
you'll have a hard time.
Also, I'm curious about your program. If you try to support all
software at once then I'll have a hard time because it will take too
long until I can test it :-)
> Also, can anyone give me a hint as to SCSI support? The specs allow
> for SCSI, but I don't know how many programs there are "out there"
> that actually use QIC-113. Also, what about IDE?
IDE tapes were probably too new to find their way into that standard,
which was written down in 1995.
> Are segment sizes limited to 29K on these as well? I'll need ioctls or
> otherwise to be able to retrieve segments by number, and also know the
> size of a segment given the number (which the bsm handling in libftvt
> gives me currently).
>
> Claus: If I support SCSI, libftvt will need it's tape I/O encapsulated
> so that SCSI calls can be made as well. Thoughts?
I think many SCSI tapes are not organized that way. Some support
seeking to blocks, some don't.
Have a look at the QIC-113 standard. For SCSI tapes without
partitions, the volume table has to be replicated at EOD, because you
cannot re-write a volume table at BOT without erasing all data.
And if there is support for partitions, then the entry is added to the
"directory partition", which probably means to position at BOT side of
the directory partition and re-write it.
Also, for QFA tapes the block-size is probably not 29k but 32k or
something which can be tuned.
But back to the question: libftvt can determine whether it tries to
talk to a floppy tape by sending ftape specific ioctls to the tape
drive.
It can determine if there is a directory partition by the MTSETPART
operation.
It can determine if it is a QFA tape by trying to send a MTSEEK ioctl.
There are more problems. E.g. what was the block-size at the time the
volume was recorded? AFAIK there is no field in whatever record
proposed by the QIC-113 standard.
There is also the question whether it is worth the effort. I don't
know whether QIC-113 is widely used for SCSI tapes? Unix like systems
most probably use tar or other back-ends which simply write the data
to the tape in their own format.
Best wishes
Claus
--
Claus-Justus Heine
[EMAIL PROTECTED]
http://www.instmath.rwth-aachen.de/~heine/
Ftape - the Linux Floppy Tape Project
Home Page : http://www.instmath.rwth-aachen.de/~heine/ftape/
Mailing-list: [EMAIL PROTECTED]
