ADSM-L

Re: [ADSM-L] Does Move Data recover space on virtual volumes?

2011-03-10 15:18:47
Subject: Re: [ADSM-L] Does Move Data recover space on virtual volumes?
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 10 Mar 2011 15:18:01 -0500
I think it might be abnormal that you have filling virtual volumes.  Are
you using scratch in your virtual volume pool? or are you pre-defining the
volumes?

I use scratch volumes so it just creates new volumes dynamically.  It then
deletes them when empty.   Once a session creates a virtual volume, it
will continue writing to it until it reaches the devclass limit, or until
the process has no more data.  After that, it should mark the volume full.
 I have many full, virtual volumes, all of different sizes.  Here is an
example where the devclass is set to a 50GB maxcap.  I have none in a
filling state.


TSM13.BFS.297918489          TAPE_WB         51.2 G     100.0       Full

TSM13.BFS.297932830          TAPE_WB           1.0 G     100.0       Full
TSM13.BFS.298005222          TAPE_WB         17.6 G     100.0       Full

Reclamation only works on Full volumes, because the empty space on filling
volumes is *supposed* to be available for writing.
It does run on filling volumes only when the volume is in a copypool and
the volume access is "OFFSITE"


Regards,
Shawn





Internet
jschneider AT USSCO DOT COM

Sent by: ADSM-L AT VM.MARIST DOT EDU
03/10/2011 01:36 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Does Move Data recover space on virtual volumes?






I was under the impression that reclamation only affected full volumes,
not filling ones.  I have had backups fail because of lack of space when
% utilization was relatively low but % migratable was high.  I checked
the reclaim stgpool help info and it does not say it excludes filling
tapes.  Am I just wasting time and delaying expiration/reclamation with
the move data process?  Maybe TSM is so easy to administer I'm just
trying to make it more interesting?

Confused,
Jim

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf Of
Shawn Drew
Sent: Thursday, March 10, 2011 12:22 PM
To: ADSM-L AT vm.marist DOT edu
Subject: Re: [ADSM-L] Does Move Data recover space on virtual volumes?

Why wouldn't normal reclamation be used for this?  It's the automatic
"move data" intended to consolidate empty space.
As long as expiration is running on both source and target server space
will be reclaimed.


Regards,
Shawn
________________________________________________
Shawn Drew





Internet
jschneider AT USSCO DOT COM

Sent by: ADSM-L AT VM.MARIST DOT EDU
03/10/2011 11:15 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Does Move Data recover space on virtual volumes?






Yes.

I use 'move data' to consolidate virtual filling volumes and reduce 'Pct
Migr' in the storage pool.  Judging by the time taken to move data,
empty space is not moved.  After the data is moved off of the volume it
becomes a scratch volume.

Jim Schneider

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf Of
Keith Arbogast
Sent: Thursday, March 10, 2011 10:08 AM
To: ADSM-L AT vm.marist DOT edu
Subject: [ADSM-L] Does Move Data recover space on virtual volumes?

We are running TSM 6.2.2.2 on RHEL 5.

It is my understanding that all the space used by a virtual volume is
kept until every file on it has been expired. Virtual volumes don't
shrink in size, just like physical cartridges, even though their
pct_utilization may go down. Therefore, if some file in a virtual volume
never goes inactive, that virtual volume will live forever and all its
space be indefinitely unreclaimable.

Are my starting point, and its consequences correct? If not, please
correct my misunderstanding.

If virtual volumes with expired files don't shrink, does 'move data' on
a virtual volume recover empty space like it does on a physical
cartridge?  Or, does the empty space get moved too?

Move data is not an efficacious solution to this problem. Is there a
better one?

With my thanks,
Keith Arbogast
Indiana University



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in
error,
please delete it and immediately notify the sender. Any use not in
accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
not therefore be liable for the message if modified. Please note that
certain
functions and services for BNP Paribas may be performed by BNP Paribas
RCC, Inc.



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.