On Wed, 23 Oct 2002, Darrell May wrote:
> Charlie Brady <[EMAIL PROTECTED]> said:
>
> > The rewind cannot be the cause of the problem,
>
> If you take an in depth look you will notice that this rewind is completely
> unneccessary based on the correct flexbackup configuration parameters. Here
> is an excerpt from my panel:
I'm happy to take an in depth look, but an in depth look involves studying
what is happening with the tape and the drive, not what you have put into
a panel.
> <panel>
> Specify whether to perform an erase and rewind before backups. Default is [
> true ]. If you find your tape drive does not correctly append multiple file
> system backups, set this to false.
>
> erase_rewind_only: true/false
Your text indicates that you are confused about this setting.
"erase_rewind_only" setting tells flexbackup to issue a "rewind" command
in place of the "erase" command. It's put there to allow flexbackup to run
on systems whose "mt" command does not understand "erase", but can also be
used on systems where the "erase" command takes a long time to run, and is
unnecessary (as, for instance, for DAT and DLT drives, which don't need to
be erased before rewriting). We have used it in-house for the latter
reason.
> Specify whether to erase the tape when doing a level zero backup. Default is
> [ true ]. If you find your tape drive does not correctly append multiple
> file system backups, set this to false.
>
> erase_tape_all_level_zero: true/false
> </panel>
>
> If you require a rewind, set the above to their defaults states 'true' and
> let flexbackup do the rewind for you.
The "erase_tape_all_level_zero" is a bit of a misnomer, especially when
"erase_rewind_only" is true. What it really means is "retension and
erase/rewind" the tape before doing level zero dump (and we only do level
zero dumps). The alternative is "go to end of data" before writing the
tape.
Here is the relevant code fragments:
...
if ($main::opt{'fs'} eq 'all') {
if ($main::level == 0) {
# All level zero - retension, and erase a new tape
# (config file may tell us not to erase)
if ($cfg::erase_tape_all_level_zero eq "true") {
$main::do_reten = 1;
$main::do_erase = 1;
} else {
$main::do_reten = 0;
$main::do_erase = 0;
}
$main::do_rewind_after = 1;
...
# Maybe retension
if ($main::do_reten == 1) {
&log('| Retensioning tape...');
&mt('retension');
}
# Maybe rewind/erase
if ($main::do_erase == 1) {
&log('| Rewinding & erasing tape...');
&mt('rewind');
&maybe_delete_old_index();
&mt('generic-erase');
$tape_key = &new_tape_key();
} else {
&mt('rewind');
$tape_key = &get_tape_key();
&log('| Making sure tape is at end of data...');
&mt('generic-eod');
}
...
This means that if "erase_tape_all_level_zero", then we do:
&log('| Retensioning tape...');
&mt('retension');
&log('| Rewinding & erasing tape...');
&mt('rewind');
&maybe_delete_old_index();
&mt('generic-erase');
$tape_key = &new_tape_key();
and otherwise we do:
&mt('rewind');
$tape_key = &get_tape_key();
&log('| Making sure tape is at end of data...');
&mt('generic-eod');
Note that "&mt('generic-erase');" equates to either:
&mt('erase');
or
&mt('rewind');
depending on the setting of 'erase_rewind_only'.
> If you find a rewind creates an invalid backup, due to incorrect tape
> positioning, set the above to 'false'. When set to 'false' we do not want to
> issue any rewind, therefore we must remove the 'rewind after dd' command.
I repeat my claim that a rewind before flexbackup runs cannot "create an
invalid backup". At most it might expose a bug in flexbackup which depends
on the position of the tape when flexbackup is executed. flexbackup should
run reliably regardless of the tape position before it is executed. If it
does not, then there is a bug in flexbackup or in one or more of the
components it runs over the top of, including particularly the various
driver modules and the drive hardware itself.
> Based on the above, in no case is the 'rewind after dd' needed.
Whether it is *needed* or not is not really the issue. It should be
harmless, even if it is not needed. What is at issue is whether it is
harmful or not. Your testing suggests that it is harmful, which is
probably a clue to where the real problem lies.
> In my direct testing, I confirmed the 'rewind after dd' directly caused
> problems with the OnStream ADR2.60.IDE TBU.
No, you did not. You only demonstrated that removing that particular
rewind was a workaround which allowed your backup (and hopefully restore
as well) to complete. The cause of the problem is still unknown.
--
Charlie Brady [EMAIL PROTECTED]
Lead Product Developer
Network Server Solutions Group http://www.e-smith.com/
Mitel Networks Corporation http://www.mitel.com/
Phone: +1 (613) 592 5660 or 592 2122 Fax: +1 (613) 592 1175
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org
