My Original Question:
---------------------
Could anynone advise me on how to dump UNIX filesystems over multiple tape
volumes in OSF/1 V3.2?
We have an 8Gb RAID array and a 5Gb TTi CTS-8510 (Exabyte) Tape unit. We
have recently filled the RAID drive past the 5.0 Gb capacity and are
encountering problems with dumping. The dump command we are using at the
present runs the dump to the end of the tape and gives an error like this:
dump: NEEDS ATTENTION: Do you want to restart this volume?: ("yes" or "no")
Should the dump program detect end-of-tape and prompt me for a new volume?
It certainly doesn't seem to recognise the end of the tape correctly for the
exabyte.
Alternatively, can I specify tape density, size, etc. parameters to force
dump to stop before the end-of-tape is reached? Having tried a number of
"fudges" such as using default density and a very small size (amounting to a
tape of capacity 1.9Mb, d=default(1600bpi), s=100ft)) , it appears that
these parameters do nothing to halt the dump after theoretical tape capacity
has been reached.
Are there any other dump parameters I need to specify?
Is there any tape device info I need to provide to OSF/1?
Are there any switches I need to set on the tape drive to provide OSF/1 with
a correct end-of-media signal?
I would be very keen to hear from anyone with experience in these matters.
Thank you in advance.
Anne E. Henderson
Tropical Remote Sensing Unit
CSIRO division of Exploration and Mining
PMB Aitkenvale PO, Townsville, 4814
e-mail a.henderson_at_dem.csiro.au
ph:(077)538544 fax:(077)538600
---------------------------------------------------------------------
Thank you to all those who replied:
Pulak Rakshit, Alan Rollow, Dave Sill, and gachamb_at_milp.lsis.loral.com.
I have appended their comments below my SUMMARY.
It appeared that my error should not have occured. I should have been
prompted for Volume 2 when EOT was reached.
I had left one of my "fudges" (using a very small tape size specification),
running yesterday, after it had proceded past the expected EOV. When it
reached the end of the tape, it prompted me correctly for Volume 2.
Based, on this observation, one explanation for my previous problems might
have been that my tape size specifications were too large. I was using a
slightly high value for -s that calculated more capacity than the tape in
fact had. Since, the dump program calculated that I only needed one tape, or
that I should not be at EOT yet, it was not looking for an EOT and so
reported an error instead. The smaller capacity specification, meant that it
was already waiting for an EOT signal.
One thing that still bugs me though is that, while dump does request a new
volume, it then proceeds to "nag" you about it if I didn't put a new tape in
by asking "Do you wish to retry the open? (yes or no)" incessantly. When I
first saw it, I thought I was getting my error message again! Is this really
necessary?
I guess if I want user-friendly maybe I should look at some of the backup
software mentioned below.
----------------------------------------------------------------------------
-----------------------
Dump prompts for next tape, so use:
# mt rewind
# dump -0f /dev/nrmt0h /device
Hope this helps
Regards
Pulak
----------------
To the best of my knowledge, our version of dump has had EOT detection
since V2.0 of ULTRIX some 8-9 years ago. This includes the version of
dump included with Digital UNIX. Some possibilities come to mind:
1. A bug in dump.
2. A bug in the tape driver that is misreporting EOT as an
I/O error.
3. A bug in the tape drive that is misreporting EOT as an
I/O error.
4. The tape drive is getting an I/O error out at the end
of the tape.
I haven't looked closely at the dump code that handles this
or the tape drivers that support it, but initially EOT does
appear to be an I/O error (failed write). Dump then uses
an I/O control supported by our tape drives to find out if
the physical tape is at EOT or not. If the drive reports
being at EOT then it can ask for a tape change (interactively).
If the drive doesn't report being at EOT, then it must assume
it is real I/O error and will ask to rewrite the tape.
At least I think this is the way it works.
-------------
>Should the dump program detect end-of-tape and prompt me for a new volume?
No. GNU tar, however, has an option to do just that. I use it
regularly to dump an 8.5GB partition.
>Alternatively, can I specify tape density, size, etc. parameters to force
>dump to stop before the end-of-tape is reached?
Yes, that's precisely how dump is intended to be used, although the
man page seems to keep it a secret. :-) It would have been much easier
if it just accepted a "capacity" parameter. You'll need to pick a size
and density that multiply out to something less that actual capacity
of the tape. Or use GNU tar.
>Are there any other dump parameters I need to specify?
No.
>Is there any tape device info I need to provide to OSF/1?
No.
>Are there any switches I need to set on the tape drive to provide OSF/1 with
>a correct end-of-media signal?
No.
>Thank you in advance.
You're welcome.
-Dave
----------------------
the ONLY way to get around this is to dump by directories. Dump does not know
how to cross tapes. Another solotion that we use is Polycenter save and
restore(lagato networker). It's gui that is slicker than dump and restore
and it
comes bundled with 3.2.
Anne E. Henderson
Tropical Remote Sensing Unit
CSIRO division of Exploration and Mining
PMB Aitkenvale PO, Townsville, 4814, Australia
e-mail a.henderson_at_dem.csiro.au
ph:+61 77538544 fax:+61 77538600
Received on Thu Sep 14 1995 - 06:53:51 NZST