So, can someone explain the difference at the TSM level and aggregate level. Really I'm trying to understand, if I have a primary disk pool that does not migrate, it will be the final onsite resting place of data. As data expires and fragmentation occurs. That space is unusable if I'm not migrating to another primary area? Eventually I'll have to allocate more? Below is what comparison doc showed as "consideration of fragmentation" for random access pools. Guess I'm not sure what the diff is between tsm level and aggregate level.
TSM level - fragmentation will occur as TSM allocates and frees space within the Storage Pool. Migration tends to relieve this fragmentation Aggregate level - fragmentation occurs as files expire within an aggregate. DISK pools cannot reclaim this wasted space until all files in the aggregate have expired -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Rushforth, Tim Sent: Tuesday, April 04, 2006 11:21 AM To: [email protected] Subject: Re: [ADSM-L] Random Access Disk Pools See http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg21218415 for comparison of disk vs devclass=file -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Park, Rod Sent: Tuesday, April 04, 2006 10:39 AM To: [email protected] Subject: Re: [ADSM-L] Random Access Disk Pools 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.
