This is a real catch-22
BIG virtual volumes means less tsm data base space tied up tracking tons of
little virtual volumes (and files on the remote server) BUT big virtual
volumes also means lots of data transfered over the network during
reclamation (sigh)

Also remember, a virtual volume is only as big as the (A) current work
process (B) defined max capacity

So even if you define a maxcap of 10 GB, if you do something like a "backup
stg" and that process only writes 2 GB, then the virtual volume will be
closed at 2 GB.  (no additional data will be written to that ~virtual
volume~)

In general, if you know you will be putting large amounts of data off to
virtual volumes that is likely to all expire together, such as a backup of
an archive storage pool that holds large DB archives, then really big
virtual volumes is the way to go since there will be very little reclamation
ever needed (since the data is likely to expire in large sets).

just my 2 cents worth...

Dwight



-----Original Message-----
From: asr AT ufl DOT edu [mailto:asr AT ufl DOT edu]
Sent: Tuesday, September 03, 2002 10:02 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Virtual Volumes...


Greetings all.  For those of you using virtual volumes, how large do you
make
the volumes?  When I started doing this, I had the following opinions:

+ The server volumes should be significantly smaller than the remote
physical
  storage.

It would be a real pain for most of the virtual volumes to be spread over
different tapes; multiple physical mounts for each virtual mount?  Ugh.


+ The server volumes should be large enough not to be a huge load.

Each virtual volume is a "file" on the hosting server.  For each TB of data,
that's 1000 files if volumes are 1G; actually probably more like 1300, with
reclamation at 50%.  You certainly don't want them as small as 100M.


I selected 1GB for my virtual volumes, but am starting to re-think the
issue,
maybe going for 10G or so.

Anyone want to share thought processes?


- Allen S. Rout