ADSM-L

Re: LTO Volume

2005-03-06 06:13:10
Subject: Re: LTO Volume
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 6 Mar 2005 06:12:52 -0500
Akash -

In analyzing problems, get into the habit of acquiring the complete
information available about the ingredients of the problem scenario so
that it becomes more understandable. In this case, problem analysis is
handicapped by not employing the Format=Detailed option of Query
commands, in particular to see the Date Last Written, and the Access
mode. (The Select command which I provided you will provide those
details as well.)

In addition to having a Status of Filling, the tapes must have an
Access mode of ReadWrite in order to be utilized for further storage
pool data. If ReadWrite, then you can compare Date Last Written on the
Filling tapes to gain perspective on a volume being "left behind", as I
explain in the material that I referenced in my prior response. The
datestamp will allow you to then examine your Activity Log for that
time period and see what caused one of those tapes to be used rather
than another.

Your Collocation policies are also a factor here. Your queries are only
listing volumes, without providing perspective on their use by node or
filespace. If you are employing Collocation, then you can utilize the
Query Content ... Count=N command to sample tape contents and determine
whether the volumes have mutually exclusive use, where having multiple
volumes in Filling status is wholly natural.

If the Filling state on a given volume is artificial (the "Tape leak"
problem I described) then you can utilize MOVe Data ... RECONStruct=Yes
to most economically append the data from an older Filling tape to a
newer one to replenish your scratch pool. Over time, you need to
periodically check for this condition, as via the Select. (Alternately,
you could pursue the issue with IBM, if you deem it a problem.)

   Richard Sims

On Mar 5, 2005, at 8:15 PM, Akash Jain wrote:

Thanks for the reply....

But this is now happening with other scratch volumes also; I mean to
say the
previous one BT00557 has been now in a state of 'FULL'
Where as other volumes checked in as scratch has occupied.

I suppose now TSM is using simultaneously 2 LTO volumes for backing up
the
data.

Output of the necessary commands as follows: -

 q vol
BT0559                    TAPEPOOL     LTOCLASS    200,000.0   15.5
Filling
BT0560                    TAPEPOOL     LTOCLASS    200,000.0    7.7
Filling
BT0556                    TAPEPOOL     LTOCLASS    490,300.6  100.0
Full
BT0557                    TAPEPOOL     LTOCLASS    528,951.4  100.0
Full

q libvol
Library Name   Volume Name   Status       Owner        Last Use    Home
Element
------------   -----------   ----------   ----------   ---------
---------
---
AUTOLIB        BT0559        Private                   Data        1
AUTOLIB        BT0560        Private                   Data        3
AUTOLIB        BT0557        Private                   Data        2

NOW YOU CAN SEE THAT BT0557 earlier in the state of 'FILLING' has now
been
displayed as 'FULL' but other 2 LTO volumes BT0559 and BT0560 is now
in the
state of 'FILLING' irrespective that BT0559 is in 15.5 percent
'FILLING'
state.

Please provide the resolution for the same or how to solve the problem?

<Prev in Thread] Current Thread [Next in Thread>