I forget to mention this in my previous message, but I have selected volume
size 64GB because of file size as well. TDP for Oracle and Mail (Exchange)
produces quite big files. In my case they are still not more than 32GB.
I totally agree with you reclamation can create very serious problem if huge
file is allocated in a few volumes. Head and tail volumes, which contain big
file and other files, can be selected for reclamation after expiration of other
files. In this case all middle FULL volumes will be reclaimed together with
head or tail volume.
But, at the same time, using very big volumes for FILE storage pool also is not
good because of wasting space and bigger amount of data during reclamation:
1) th=50 is saving space, but increases amount of data during reclamation (for
256GB volumes it can reach 128GB);
2) th=80 is reducing amount of data during reclamation, but leading to bigger
wasted disk space;
3) th=100 is preventing reclamation at all, but leads to huge wasted disk
space. I wouldn't advise to use th=100 for FILE storage pools at all.
So selecting correct value for MAXCAP is not very simple procedure.
Grigori G. Solonovitch
Senior Technical Architect
Information Technology Ahli United Bank Kuwait http://www.ahliunited.com.kw
Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: Grigori.Solonovitch
AT ahliunited DOT com
Please consider the environment before printing this Email
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Johnny Lea
Sent: Tuesday, September 21, 2010 6:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] 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.
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.
|