ADSM-L

Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux)

2010-09-22 06:41:34
Subject: Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux)
From: Grigori Solonovitch <Grigori.Solonovitch AT AHLIUNITED DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Sep 2010 13:39:29 +0300
>Also, do you have a (fast) DISK based volume in front of the FILE storage 
>pool?  We do this >so we can allow lots of client backups coming in and use 
>the number of migration processes >to control the data streams to the FILE 
>storage pool.

Yes, I had DISK pools before, but I have migrated all of them to FILE to be 
able to use TSM Server de-duplication. In my opinion, everybody can use DISK 
storage pool as less painful till you do not need de-duplication.
Now about performance:
- I am using JFS2 file systems on FATA disks (RAID5 and RAID6) and I was not 
able to see big difference in performance after migrating DISK --> FILE. 
Actually IBM stated the same in some documents;
- I think disk performance is a matter of disk interface (number of adapters, 
adapter type, number of paths, switches, etc) and total number of disks (RAID 
type, number of RAID arrays, number of disks in RAID array).



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 
Stef Coene
Sent: Wednesday, September 22, 2010 12:29 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - 
Part Deux)

On Friday 17 September 2010, you wrote:
> From the few responses I got about  6.1.4.x vs 6.2.1.1 for a new server,
> the responses leaned to 6.2.x.
>
> With that decision made, the next is laying out the structure of storage
> pools and such.
>
> Most discussions/directions from here/IBM say that DEVCLASS FILE is the
> way to go vs defining fixed storage volumes/pools for disk (or in this
> case SAN)
>
> So, have you migrated to devclass FILE?
>
> 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?
Also, do you have a (fast) DISK based volume in front of the FILE storage
pool?  We do this so we can allow lots of client backups coming in and use the
number of migration processes to control the data streams to the FILE storage
pool.

We also have 2 very very very busy 5.x servers with DISK storage pools.  We
are trying to migrate them to FILE based storage pools.  We started with 100GB
volumes but this was a disaster.  Total storage is 17TB and 32TB.
The server was running reclamation for the FILE based storage pools, backup to
a remote FILE based storage pool and backup to a tape based local storage pool
at the same time.  Not good.
When we changed the FILE based storage pool to 5 GB volumes, the result was
much better.  There was less reclamation needed because it is less likely that
a volume has a status Filling.


Stef

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Please consider the environment before printing this Email.

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.

<Prev in Thread] Current Thread [Next in Thread>