On Monday 25 October 2004 17:53, Joe Rhett wrote:
>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.
If the file cannot be restarted from byte 1 on the next tape, eg the
system cannot back up to the start of the file being written, then
something is seriously wrong with the method being used. In the case
of no holding disk, then it seems setting one up would be the answer.
In no event will amanda actually "continue" a file on the next tape,
its a basic design decision, and while there have been some patches
available from 3rd parties to do this, I'm certainly not privy to any
discussions as to the feasability of incorporating such a bug/feature
into an actual amanda distribution. And the dual labeling of such a
method above is 100% intentional.
>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.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
