Well, no responses, but I've fixed the problem.
I tried an nsrck -mv, but this had no effect.
I then did a verbose dump of the contents of one of the real records
(mminfo -aVS CL0074 >logfile.1).
Deleted the funny record from the database using the volumes window.
Re-ran the above check into a new file and diff'd them to make sure that
removing the shadow record had no effect on the real one.
Having proved the point on one, I proceeded to delete the other 15
shadow records.
Ta.
Will
Will Parsons wrote:
Hi All,
One of our operators had some finger trouble this morning and killed
nsrd :-(
As the system came back up, the databases got checked.
However, it appears there's something not right in the media database,
as some of the volumes have a second "shadow" entry listed if you
browse the volume list.
nsrmaster# (12) mminfo -m "~CL0074-1"
volume written (%) expires read mounts capacity
E ~CL0074-1 321 GB full expired 200 GB 187 190 GB
nsrmaster# (13) mminfo -m CL0074
volume written (%) expires read mounts capacity
CL0074 301 GB full 04/07/05 569 MB 193 190 GB
I imagine that this will need the media database re-checking at some
level, but I thought I'd ask if anyone had seen this before, and is a
media DB re-check enough to clear it??
Thanks in advance.
From
Will
--
w.parsons AT leeds.ac DOT uk
UNIX Support
Information Systems Services
The University of Leeds
+44 113 343 5670
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|