On Wed, 7 Feb 2001, John R. Jackson wrote:
> >Okay, but now we're back to requiring manual intervention here to load
> >that tape and do the amflush ... what about an automatic feature for this?
> >... don't write to tape until we can fill the tape. ...
>
> I proposed something called "autoflush" a few weeks ago. Maybe this
> can be folded in. I'll add it to the notes.
>
> I suspect the tape I/O would be triggered by either the holding disk or
> tape length being met so it would work either way (holding disk bigger
> than tape or vice versa).
That sounds perfect :)
> >What is the difference between what happens now (you write a file system
> >to tape, when the next one is ready, you spin up the tape and write the
> >next one to tape) and appending to tape? ...
>
> The difference is that taper has the tape device open the whole time it
> is running. If a SCSI reset happens, taper will get an I/O error.
>
> What people usually mean by "append to tape" is that the next run starts
> up where the last left off. But during that time, **anything** could
> have happened to the tape or drive without any part of Amanda knowing
> about it, and that's harder to deal with when the next run starts.
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? 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? Once the rew starts, you've gotten your lock on the device, so
again have your I/O error if a SCSI reset happens, no? And I imagine that
the tape is already marked as to where the end of the last backup
happened? Some EOBackup marker or something?
The whole autoflush thing, IMHO, negates this requirement for me, but it
just sounds so much like somethign taht would just add two->three steps to
the tape preparation process ... do I know this tape, should there be room
at the end of it, if so, rew and move ahead to where I need to be ...
