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:[EMAIL PROTECTED] Im > Auftrag von Andrew Carlson > Gesendet: Dienstag, 4. April 2006 19:15 > An: [email protected] > 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > On Behalf > > Of > > Andy Huebner > > Sent: Monday, March 27, 2006 11:43 AM > > To: [email protected] > > 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:[EMAIL PROTECTED] > On Behalf > > Of > > Park, Rod > > Sent: Monday, March 27, 2006 6:45 AM > > To: [email protected] > > 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:[EMAIL PROTECTED] > On Behalf > > Of > > Andy Huebner > > Sent: Friday, March 24, 2006 3:37 PM > > To: [email protected] > > 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:[EMAIL PROTECTED] > On Behalf > > Of > > Andrew Carlson > > Sent: Friday, March 24, 2006 11:04 AM > > To: [email protected] > > 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. >
