On Mon, Oct 25, 2004 at 03:29:52PM -0500, Frank Smith wrote:
>   First, you should probably adjust your tapelength to be slightly shorter
> than where it hits EOT (check all the sizes in the taper lines of your
> reports to see how much can actually be written).

Why is this still an issue?  I remember when this was decided upon because
a lot of tape drives were inconsistent about EOT, but that was many years ago!

No other tape program that I am aware of will throw away the entire tape
full of backups because it hit end of tape.  And the vast majority will
just stream data until EOT, and then restart the current block on the next 
tape.  This particular failure mode seems to be archiac at this point.  
Why aren't we past this?

In particular, the alpha documentation for amanda indicates that amanda
will move on to the next tape for EOT -- this apparently isn't true at all.

11.3.2 End of tape handling
As in earlier versions of AMANDA, taper itself does not try to restrict writing 
to the tape
size given in the config file. It relied on planner having correctly estimated 
backup sizes
and limiting itself to what would fit on one tape.

Now, taper needs to switch to a new tape when the current tape has filled up. 
The tape is
considered full when taper gets a write error. This will most likely occur in 
the middle of
writing a (potentially large) backup file, perhaps even from a direct-to-tape 
socket, so there
is no possibility of starting the backup file over again on the next tape, it 
must start from
where it left off, rewriting the block that got the error on the next tape.

To insure correct operation, the file header of the continued file should 
contain an indication
that it is a continuation, and at what offset. amrestore of course needs to be 
aware of this
scheme and handle it correctly, perhaps by double-buffering internally.

-- 
Joe Rhett
Senior Geek
Meer.net