Lisa,
FWIW, I haven't seen this behavior on my 5.1 server yet, but I have seen it
frequently on my 4.2 server.
Just from observation (I know it's not what the doc says), the mountwait
will cancel the process if it is waiting for a mount POINT OK, but doesn't
when the mount is needed in the middle of a process that already has the
drive.
When I have seen this, it's always been a problem with the tape robot.
-----Original Message-----
From: Lisa Cabanas [mailto:cabanl AT MODOT DOT NET]
Sent: Wednesday, May 21, 2003 8:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: more to mountwait than devclass definition??
I am wondering if I missed something in the upgrade to 5.1, but is there
somewhere else other than the devclass definition where I would define the
mountwait?
I ask because 140340 seconds is a lot more than 5 minutes!
thanks
lisa
Process Process Description Status
Number
-------- --------------------
-------------------------------------------------
13 Space Reclamation Offsite Volume(s) (storage pool BACKUPCOPY),
Moved Files: 117371, Moved Bytes:
101,969,883,939, Unreadable Files: 0,
Unreadable
Bytes: 0. Current Physical File (bytes):
606,188~Waiting for mount of input volume
771191
(140340 seconds).~Current output volume:
831191.\
Device Class Name: 3590TAPE
Device Access Strategy: Sequential
Storage Pool Count: 4
Device Type: 3590
Format: DRIVE
Est/Max Capacity (MB):
Mount Limit: DRIVES
Mount Wait (min): 5
Mount Retention (min): 0
Label Prefix: ADSM
Library: MODOT3494B
Directory:
Server Name:
Retry Period:
Retry Interval:
Shared:
Last Update by (administrator): CABANL
|
