ADSM-L

Re: Virtual Volume Copy Pool Reclamation....

2006-03-21 10:10:18
Subject: Re: Virtual Volume Copy Pool Reclamation....
From: "Pope, Simon R. (IR Computing)" <spope AT WESTERNPOWER.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 21 Mar 2006 15:09:32 -0000
Hi Allen

We've just set up a new TSM infrastructure with disk (random) and SATA
primary stgpools and a virtual volume copy stgpool. (Server 5.3.2 on AIX)
Reclamation of the virtual volumes appears to work in the offsite manner ie
we see multiple mounts of SATA volumes to build the new virtual volume. (see
below)
Does it make any difference if the virtual volumes are being used for
primary or copy storage pools?

We do seem to be experiencing problems with the virtual volumes expiring but
that's another story!

Regards
Simon

tsm: TSM>q proc

 Process     Process Description      Status

  Number
--------     --------------------
-------------------------------------------------
      53     Space Reclamation        Offsite Volume(s) (storage pool
XXXXPOOL),
                                       Moved Files: 7326, Moved Bytes:
420,145,131,
                                       Unreadable Files: 0, Unreadable
Bytes: 0.
                                       Current Physical File (bytes): None
Current
                                       input volume:
/file_vol2/00000904.BFS. Current
                                       output volume: TSMDR.BFS.142952216.

      54     Space Reclamation        Offsite Volume(s) (storage pool
XXXXPOOL),
                                       Moved Files: 6215, Moved Bytes:
556,310,593,
                                       Unreadable Files: 0, Unreadable
Bytes: 0.
                                       Current Physical File (bytes):
377,684,569
                                       Current input volume:
/file_vol1/00000903.BFS.
                                       Current output volume:
TSMDR.BFS.142952226.

tsm: TSM>q mount
ANR8333I SERVER volume TSMDR.BFS.142952216 is mounted R/W, status: IN USE.
ANR8333I SERVER volume TSMDR.BFS.142952226 is mounted R/W, status: IN USE.
ANR8333I FILE volume /file_vol10/sata0638.dsm is mounted R/O, status: IN
USE.
ANR8333I FILE volume /file_vol1/00000903.BFS is mounted R/O, status: IN USE.
ANR8334I         4 matches found.


-----Original Message-----
From: Allen S. Rout [mailto:asr AT UFL DOT EDU]
Sent: 17 March 2006 15:59
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Virtual Volume Copy Pool Reclamation....

_________________________________________________________________

Greetings, all.

I'm trying to work out exactly how IBM thinks virtual volume reclamation is
supposed to proceed, and also how we think it does in fact proceed. ;)


Noodling around in the docs and QuickFacts, I find that volumes of a
devclass of type SERVER "may not be set to access=offsite", and
experimentation confirms this.


Such would lead me to the conclusion that SERVER devclass volumes would be
reclaimed in a manner logically equivalent to local volumes, to wit a source
virtual volume and a target virtual volume would both be mounted, the source
read from and the target written to.  This is also what Dave said in Oxford,
and what I see happening on some of the servers.

However, on one of them servers I observe reclamation proceeding in the
'offsite' manner, with a new virtual volume being built from
(many!)  mounts of primary volumes.  I'm not sure how I can control this,
but the difference is giving me the aggravations something fierce.  I can
see circumstances in which I might want to do things in either way, but
optimizations in favor of one are a pain for the other.


Any ideas?



- Allen S. Rout

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

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