I increased my windows server devclass volume size to 50GB and database 
devclass to 200GB.
If reclamation is not involved then I don't know if it really matters as to 
volume size.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray/AC/VCU
Sent: Tuesday, September 21, 2010 12:04 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - 
Part Deux)

So, what did you increase the size to?

Just in case I don't completely understand the pros/cons of FILE vs DISK,
I plan to use this 5.3TB SAN disk space the same way I am using DISK on my
other servers - LZ for incoming backups and then migrate to disk.  Folks
keep talking about reclamation of their FILE devclass storage.  I would
never be doing that - just moving the backups to primary tape after making
offsite copies (which I hope to implement as a duplex/simultaneous
operation with 6.2.x)



From:
Johnny Lea <jlea AT UMC DOT EDU>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
09/21/2010 11:36 AM
Subject:
Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part
Deux)
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



I am using file class on datadomain albeit 5.5.3.  Initially I set the
maxcap at 25GB.  This seemed to work OK except my reclamation is getting
out of hand.  For example a 200GB file stored across several volumes is
requiring the entire 200GB being moved instead of only the part of the
file on the volume getting reclaimed.
I've since tried to match volume size with average file sizes in a
particular domain.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Grigori Solonovitch
Sent: Friday, September 17, 2010 2:49 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server
- Part Deux)

>So, have you migrated to devclass FILE?
        I have migrated most of primary pools to devc/stgpool FILE and
found them perfect (it was done as a preparation to use de-duplication in
6.x, by the way am still 5.5.4). It is good from any point of view(backup,
restore, making tape copies, etc). There is only one big disadvantage -
cost of solution. By the way, with future de-duplication we are going to
gain something in cost as well.

> For folks that are using devclass FILE, what values did you use for
MAXCAP
> and/or MOUNTLimit?  How do you calculate/arrive at these numbers?
> Pro/con's for just letting the system determine MAXCAP?
     I was trying to find some information about calculating correct
MAXCAP without any success. I think suitable MAXCAP is 32GB, 64GB, 128GB
or 256 GB. I formated all primary pools with 64GB volumes and found no
problems. Using bigger volumes can cause some problems. For example, it
can limit number of mounts (parallel operations) - for volumes 256GB in
2TB storage pool number of mounts is limited to 8, because there is only 8
volumes in storage pool. I think values for MAXCAP and MOUNTLIMIT totally
depend on size of storage pool and required number of parallel operations
(backup and restores). KEEP IN MIND - MOUNTLIMIT is working only if there
is enough volumes with status FILLING or EMPTY. FULL volumes can be
mounted only for restore operations. Of course, problem can be resolved by
creating required number of empty volumes, if there is no limit in storage
pool size, but it is a dream of every admin.

CONFIDENTIALITY AND WAIVER: The information contained in this electronic
mail message and any attachments hereto may be legally privileged and
confidential. The information is intended only for the recipient(s) named
in this message. If you are not the intended recipient you are notified
that any use, disclosure, copying or distribution is prohibited. If you
have received this in error please contact the sender and delete this
message and any attachments from your computer system. We do not guarantee
that this message or any attachment to it is secure or free from errors,
computer viruses or other conditions that may damage or interfere with
data, hardware or software.

Please consider the environment before printing this Email.


Individuals who have received this information in error or are not
authorized to receive it must promptly return or dispose of the
information and notify the sender. Those individuals are hereby notified
that they are strictly prohibited from reviewing, forwarding, printing,
copying, distributing or using this information in any way.


Individuals who have received this information in error or are not authorized 
to receive it must promptly return or dispose of the information and notify the 
sender. Those individuals are hereby notified that they are strictly prohibited 
from reviewing, forwarding, printing, copying, distributing or using this 
information in any way.