SUMMARY: vdump strangeness

From: Andrew Raine (Andrew.Raine@mrc-dunn.cam.ac.uk)
Date: Wed Oct 16 2002 - 05:34:23 EDT


(I composed this summary 2 weeks ago, but forgot to send it - many
apologies)

Dear Managers,

It seems that the behaviour I see with my NEO Overland SDLT is the one
expected from vdump (I still don't know why I don't see it with the
DLT8000).

I should be using the -N option to suppress the rewind, and I probably
need to install PK5 so that vdump doesn't crash when I use the -N
option...

In the interim, I'll probably end up using an "mt seod" to get back to
the end of the tape after each fileset.

Thanks again for your help.

The answers I received:

Dr Thomas Blinn:

I have exactly zero personal experience with either of the two tape
library devices you mention, but I do know that there are some tape
libraries that "automagically" switch to a new tape (rewind, eject,
load next, position to BOT, keep going) when they reach physical
end of tape and the system keeps presenting data, and there are some
others that return an "end of tape" indication to system software,
and rely on system software to initiate a switch to the next tape.

"vdump" itself has NO support at all for dealing with changers; if
the changer does the "automagic" media switching, it's happy, since
as far as it knows it's just continuing to write to a single tape
volume. But if the changer returns "end of volume" then "vdump" is
going to rewind and eject the tape and ask the operator for the
next tape volume (this does NOT work very well, and especially not
in a "batch" job, since "vdump" insists on talking to /dev/tty not
to standard input).

Again, I don't have personal experience with your media changers,
but I do know some of the variations in behavior and I know that
"vdump" is NOT very good with changers that don't "automagically"
switch the tapes for you.

Tom

Paul Wilson:

We have also had problems using vdump on 5.1. Looking further into it,
patchkit 5 has a number of vdump fixes.
It may be worth taking a look.

Jim Belonis:

regardless of the kind of device you use, vdump likes to send a rewind
command when it is done. use the -N command-line option in vdump to
disable this behaviour.

Original Question:

> Dear Managers,
>
> I've been having difficulties with my vdump scripts, using a NEO
> Overland tape library containing an SuperDLT drive. Vdump seems to
> behave differently on this system than it does on my TL800 containing a
> DLT8000 drive.
>
> What I am seeing is that *vdump* is rewinding the tape at the end of
> the job, when using the NEO/SDLT, but doesn't using the TL800/DLT.
> (Furthermore, if there are errors, then the NEO/SDLT goes offline, but
> the TL800/DLT doesn't - but this isn't my main problem).
>
> I'm pretty sure that I am using the non-rewind devices in both cases:
>
> beta # cd /dev
> beta # ls -l DLT0 SDLT0
> lrwxrwxrwx 1 root system 14 Jul 23 14:52 DLT0 -> ntape/tape0_d1
> lrwxrwxrwx 1 root system 14 Jul 23 14:52 SDLT0 -> ntape/tape3_d1
>
> My vdump commands were:
>
> /sbin/vdump -0 -u -b 64 -f /dev/DLT0 <fileset>
>
> and
>
> /sbin/vdump -0 -u -b 64 -f /dev/SDLT0 <fileset>
>
>
> I noticed, that the man-page describes options:
>
> -N Does not rewind the storage device when it is a tape.
> -U Does not unload the storage device when it is a tape.
>
> However, including -N, or both of these causes vdump to exit with a
> Segmentation fault. Including just -U doesn't stop the tape rewinding.
>
> Can anyone tell me
>
> (a) whether it is vdump that is doing the rewinding and ignoring the
> choice of non-rewinding tape device?
>
> (b) is there anything else that I've missed, or do I just need to make
> my scripts explicitly forward the tape again (using mt) after each
> vdump?
>
> I'm running 5.1 PK3 on an ES40
>
> Regards,
>
> Andrew

Andrew

--
Dr. Andrew Raine, Head of IT, MRC Dunn Human Nutrition Unit, 
Wellcome Trust/MRC Building, Hills Road, Cambridge, CB2 2XY, UK
phone: +44 (0)1223 252830   fax: +44 (0)1223 252835
web: www.mrc-dunn.cam.ac.uk email: Andrew.Raine@mrc-dunn.cam.ac.uk


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:56 EDT