Why don't you use random and sequential together?
In our diskonly setup we use 3 types:
2% fibrechannel disk as primary pool with random access for daily backup
sizelimit 2MByte
30% ATA disk as primary pool with random access volumes for backup no sizelimit
migdelay=7days
68% ATA disk as primary pool with files device for migrationtarget of ATA Pool
and for direct target of TDP agents
and
100% ATA as copypool on remote site. (Copy is done as an extra step since we
got very high CPU load)
No problems since one year.
Kind regards
Stefan Holzwarth
> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> Auftrag von Andrew Carlson
> Gesendet: Dienstag, 4. April 2006 19:15
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: Random Access Disk Pools
>
> Rod,
>
> After spending 4 weeks using file device class disk pools, I would say
> use random access. Here is why:
>
> The speed of the random access disk pools is phenomenally better than
> the file device class - not sure why though
>
> The volumes (from the presentation I just read from the other email)
> are supposed to be picked based on filesystems with no volume
> mounted.
> What I found is the it selects them in collation order. This accessed
> the volumes on one raid group, giving the worst performance of all.
> After using a kludgy method to spread the data around, the performance
> was better, but did not approach random access
>
> Small files were a problem in some cases. Since I was collocating, if
> alot of small files were written to a volume (in this case, it was
> moving my dirmc pool), there can be alot of wasted space. Apparently,
> a block of 256K is written to disk no matter how much data is being
> written. If alot of small files are written to a volume, space can be
> wasted because the volume will fill before capacity is
> reached (we were
> using predefined volumes)
>
> It takes alot of time to predefine the volumes. We were finding it
> took about 19 hours to predefine 2TB. We were able to run 8 of those,
> so it ended up taking 19 hours to predefine 16TB, but that is still a
> long time.
>
> Some portion of space is taken up by volumes that are not yet full
> (with predefined volumes at least) in a file device class.
> This is not
> a worry with random access, but fragmented aggregates could
> be a worry.
>
> My plan is to move data off of random access volumes on the
> weekends to
> help prevent fragmentation.
>
> If you have any other questions, please let me know.
>
> --- "Park, Rod" <rod.park AT TYSON DOT COM> wrote:
>
> > Let me ask again because I didn't get much feedback. How do we find
> > the
> > thread limit, and can people weigh in on whether they use big disk
> > pools
> > (50TB-200TB). The advantages/disadvantages of big disk pools versus
> > devclass=file any gotchas either way. We are looking at buy a lot
> > more
> > disk and creating big diskpools to land data on and be the primary
> > pool
> > instead of tape. Thank in advance.
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf
> > Of
> > Andy Huebner
> > Sent: Monday, March 27, 2006 11:43 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] Random Access Disk Pools
> >
> > We found the limit. There are some posts in this forum from the
> > first
> > of the year about the problem we ran into.
> >
> > Andy Huebner
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf
> > Of
> > Park, Rod
> > Sent: Monday, March 27, 2006 6:45 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] Random Access Disk Pools
> >
> > We use random access pools, how do you know what your thread limit
> > is....we've never had any issues with ours but we're thinking about
> > adding a lot more. What's the biggest reason you do/don't use
> > devclass=file over disk storage pools....arguments either way?
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf
> > Of
> > Andy Huebner
> > Sent: Friday, March 24, 2006 3:37 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] Random Access Disk Pools
> >
> > Be careful with how many disk pool volumes you create. Each volume
> > uses
> > 1 thread, add this to all of the other threads in use, our
> TSM server
> > would die at around 1800 active threads.
> >
> > Andy Huebner
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf
> > Of
> > Andrew Carlson
> > Sent: Friday, March 24, 2006 11:04 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: [ADSM-L] Random Access Disk Pools
> >
> > I have heard in the past that random access disk pools can become
> > fragmented and practically unusable after a while. I was wondering
> > if anyone sees this in the real world? I posted the other day about
> > managing predefined volumes in a file type devclass, and the only
> > answer I got said they were using random access pools. I would MUCH
> > rather have a random access pool, so if there is no problem with
> > this, I will convert over to random access. Thanks for any input.
> >
> > TSM 5.3.2.3 on AIX 5.2.5 EMC Clarion Disk, 120 TB in 2TB LUN's
> >
> > Andy Carlson
> >
> --------------------------------------------------------------
> ----------
> > ---
> > Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License:
> > $8.95/month,
> > The feeling of seeing the red box with the item you want in
> > it:Priceless.
> >
> >
> > This e-mail (including any attachments) is confidential and may be
> > legally privileged. If you are not an intended recipient or an
> > authorized representative of an intended recipient, you are
> > prohibited
> > from using, copying or distributing the information in this
> e-mail or
> > its attachments. If you have received this e-mail in error, please
> > notify the sender immediately by return e-mail and delete all copies
> > of
> > this message and any attachments.
> > Thank you.
> >
> >
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the addressee. If you are not the
> > intended addressee, then you have received this email in error and
> > any
> > use, dissemination, forwarding, printing, or copying of
> this email is
> > strictly prohibited. Please notify us immediately of your unintended
> > receipt by reply and then delete this email and your reply. Tyson
> > Foods,
> > Inc. and its subsidiaries and affiliates will not be held liable to
> > any
> > person resulting from the unintended or unauthorized use of any
> > information contained in this email or as a result of any additions
> > or
> > deletions of information originally contained in this email.
> >
> >
> > This e-mail (including any attachments) is confidential and may be
> > legally privileged. If you are not an intended recipient or an
> > authorized representative of an intended recipient, you are
> > prohibited
> > from using, copying or distributing the information in this
> e-mail or
> > its attachments. If you have received this e-mail in error, please
> > notify the sender immediately by return e-mail and delete all copies
> > of
> > this message and any attachments.
> > Thank you.
> >
>
>
> Andy Carlson
> --------------------------------------------------------------
> -------------
> Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters
> License: $8.95/month,
> The feeling of seeing the red box with the item you want in
> it:Priceless.
>
|
