On Wed, 7 Feb 2001, John R. Jackson wrote:
> >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.
That depends on how "smart" you want to make it ... why can't tape
operations happen while the dump to the holding disk is happening? We are
all working with multi-process systems ... if the code went the route that
the holding disk, or tape, has to be full before dumping to tape, then
there should be alot of time in there for taper to find the first tape it
can use/append to ...
Now, am not 100% certain on how taper does write the files to tape, but,
if I'm thinking right, each file system/dump creates a new 'fsf tag',
right? Why not sure the last one in tapelist, and/or amount of tape used?
so, now you are effectively doing an 'mt fsf <last field>' to get to end
of tape ... if you store the amount of tape saved to that tape, you would
be able to pre-determine whether or not there is even any room left on
that tape to be worth the effort (ie. say if estimated tape left is <10%,
just start a new tape) ...
> 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.
Okay, not quite sure what the 'end marker' would be used for ... if I do a
dump to tape, using dump, onto the no-rewind device, and put n file
systems onto that tape, there is no 'end marker' put onto the tape, is
there? so, instead of an 'end marker', why not create a 'dummy dump' at
the end of a tape ... so that the last file system dump'd is "fsf n", the
dummy dump is at "fsf n+1", and you can do a 'rew;fsf n+1' to start the
next dump?
Of course, all of this is moot if the concept of an autoflush on full
holding disk/full tape is possible, since it eliminates the requirement to
append :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
