ADSM-L

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

2010-09-22 11:53:13
Subject: Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux)
From: Johnny Lea <jlea AT UMC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Sep 2010 10:49:51 -0500
My idea was to create volumes large enough to hold all or large portions of 
entire files of this size.  I haven't been doing this long enough for mass 
expirations to take effect yet so I don't know for sure how it's going to turn 
out.
I don't use any diskpool buffer.  I send data straight to a Datadomain 880.

-----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 10:28 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - 
Part Deux)

On Wednesday 22 September 2010, you wrote:
> On Friday 17 September 2010, Stef Coene wrote:
> > 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.
>
>
> Interesting concept Stef...just the opposite of what I did to fix the
> problem.  I'll give this a try also. Have you seen any downside to this
> due to the large number of files in a given directory?  I'm running RHEL
> 5.4 64 bit on ext3.
This is an AIX server with a 7 TB jfs2 filesystem with 1381 files in it.
For now, no downside found.

Why have you changed to bigger FILE volumes?
And do you use a DISK based storage pool as 'buffer'?


Stef


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.