>This part always got me ... the first thing anyone is supposed to do is do
>an 'amcheck' to check for the existiance of a tape, right?  ...

Taper basically does the same thing w.r.t. the "right" tape, so amcheck
is not really an issue (in fact it's a problem because Amanda looses
control again between when it runs and when taper starts).

>If current
>tape is a known label *and* is active (not full), why not just issue a
>'rew' on the device and the fast-forward to the "end" and continue from
>there?  ...

Three reasons.  First is that this is not what some people think of
as "appending'.  The fsf can be an expensive (time-wise) operation and
they literally want to trust the drive to still be positioned at the
right place and just start writing.  Note that you cannot even check
the label in this case to be sure it's the right tape.  I don't think
this will ever fly.

Second is that positioning sounds nice and logical to a programmer or
someone only used to working with disk, but when you throw in the reality
of a physical tape device, bad stuff starts to happen.  I've seen drives
skip tapemarks, think they saw extra ones, write a few in the middle for
no good reason and just about anything else you can imagine.  So the "fsf
to the end" operation has to be very careful that it ended up where it
wants to be (and don't talk to me about "eom" -- that's nothing more
than an "infinite" fsf and ignore the error when you bang into EOT).
On the other hand, it wants to be as efficient as possible on devices
that do fast forward spacing, in other words, it would be a bad idea to
read a label, skip a file, read a label, skip a file, and so on.

Third, you never, **ever** want to change directions on a tape, except to
rewind clear back to the beginning.  So when we find the Amanda end marker
(yes, there is one), we do **not** want to back up over it and start
writing there.  Instead, we'll want to write the next image after that.
That, in turn, will affect amrestore, etc.

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to