Re: [Dump-users] Problems spanning tapes with dump

[Tom H. <tr...@ti...>]

Thanks for your reply, Eric.

Eric Jensen wrote:

>Hi,
>   Dump is indeed expecting to have a tty to talk to.  A couple of
>things you might try, neither of which I've attempted:
>
>1.  Run "expect", and use it to talk to dump.  I've never used it, but
>    my understanding is that it's made for exactly this sort of thing.=20
>
>2.  Try using this facility, described in the dump man page:
>
>     -F script
>         Run script at the end of each tape. The device name and the cur=
=81=AD
>         rent volume number are passed on the command line.  The script
>         must return 0 if dump should continue without asking the user t=
o
>         change the tape, 1 if dump should continue but ask the user
>         to change the tape.  Any other exit code will cause dump to
>         abort.  For security reasons, dump reverts back to the real use=
r
>         ID and the real group ID before running the script.
>
>Seems like you could have a simple script that would just wait however
>long it will take your changer to change the tape (plus some safety
>margin), and then return 0, so that dump would continue.  So this could
>just be
>
>#!/bin/sh
>
>sleep 5m
>exit 0
>
>and you should be set.  You probably don't even need the exit line,
>since sleep ought to return zero if it executes successfully (I think).
>
>
>I've never tried this, but it looks like what you need.  Let us know if
>it works.
>
>Thanks,
>
>Eric
>
Yes, I tried exactly that already. Great minds thinking alike and all=20
that, hey? Mine slept for 2 minues, then did an exit 0.

This had mixed results. Dump was satisfied, and did not complain about=20
needing to talk to a device, but unfortunately, the tape did not rewind=20
either. It just stayed at the the EOT mark, so when dump started up=20
again, there was no tape to write to. Here's the output:

DUMP: End of tape detected
DUMP: Closing /dev/rmt/0hn
DUMP: Volume 1 completed at: Wed Nov 19 10:02:51 2003
DUMP: Volume 1 12319800 blocks (12031.05MB)
DUMP: Volume 1 took 1:10:02
DUMP: Volume 1 transfer rate: 2931 kB/s
DUMP: Launching /opt/adm/scripts/fix_linux_tape_change
DUMP: Volume 2 started with block 12319771 at: Wed Nov 19 10:04:51 2003
DUMP: Volume 2 begins with blocks from inode 1799313
DUMP: EOT detected at start of the tape!
DUMP: The ENTIRE dump is aborted.

What should happen is that when the tape drive recognizes an EOT, it=20
rewinds the tape and loads the next one (it is in sequential mode, not=20
random mode). The Solaris man page shows this for the ufsdump "-l" option=
:

l Autoload. When the end-of-tape is reached before
the dump is complete, take the drive offline and
wait up to two minutes for the tape drive to be
ready again. This gives autoloading (stackloader)
tape drives a chance to load a new tape. If the
drive is ready within two minutes, continue. If it
is not, prompt for another tape and wait.

Maybe I'll just try an "rsh ${TAPEHOST} mt -t /dev/rmt/0 rewoffl" before=20
the sleep in my fix_linux_tape_change script, and see if that fixes it.=20
(Actually, I just tried that manually, since the tape was at the end=20
from last night's aborted attempt anyway, and the autochanger loaded the=20
next tape, so here's hoping....)

I'll post the results tomorrow.

-Tom

--=20
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
tr...@ti...      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________