We are planning a similar implementation by using 2nd server
specifically for clients with small files (desktop/workstations) as it
is choking our main server.

The below comment about tracking a lot of smaller volumes is trivial
compared with the cost of larger volumes on network load.
A restoration of files spanning multiple large volumes will be even more
painful.

How big is the storage pool going to be?  Are you tailoring the
implementation for backup, or restoration?

Why not have 2 virt volume pools using diffent sizes reflecting
small/large occupancy.

Also, create it's own storage pool hierarchy on the remote server.
This means you can buffer incoming virt volumes in it's own diskpool.
If you can find an easy/automated way of reclaiming virtvols on tape to
disk, on the remote server, then reclaiming on the virtual server, you
can take the predictable load off scarce tape drive resource.

Suad
--


On Fri, 2002-09-06 at 00:54, Cook, Dwight E wrote:
> 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