I had the same problem and then I just kept the low maxcap and set reclaim=100 
for the stgpool that housed most of the large files with simlilar 
retention(Exchange, Oracle). Not sure if this is applicable to your setup.



HC





________________________________

Fra: ADSM: Dist Stor Manager på vegne av Johnny Lea
Sendt: ti 2010-09-21 17:30
Til: ADSM-L AT VM.MARIST DOT EDU
Emne: Re: Determining devclass FILE values (a.k.a. New Server - Part Deux)



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.



This email originates from Steria AS, Biskop Gunnerus' gate 14a, N-0051 OSLO, 
http://www.steria.no. This email and any attachments may contain 
confidential/intellectual property/copyright information and is only for the 
use of the addressee(s). You are prohibited from copying, forwarding, 
disclosing, saving or otherwise using it in any way if you are not the 
addressee(s) or responsible for delivery. If you receive this email by mistake, 
please advise the sender and cancel it immediately. Steria may monitor the 
content of emails within its network to ensure compliance with its policies and 
procedures. Any email is susceptible to alteration and its integrity cannot be 
assured. Steria shall not be liable if the message is altered, modified, 
falsified, or even edited.