We've toyed with using a disk pool based on devclass devtype=file. The upside is this pre-allocation problem is not an issue. The downside is the definition for the device class doesn't allow you to specify multiple devices. So there needs to be some way to aggregate your devices into one big thing (and RAID5 is probably NOT the right thing to do).
There are other issues with this approach, like reclamation and caching, etc., that should be considered. But this idea might have merit in this case. Kelly J. Lipp STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU]On Behalf Of Matt Simpson Sent: Wednesday, October 23, 2002 5:51 AM To: [EMAIL PROTECTED] Subject: Re: Co-location At 12:06 AM -0500 10/23/02, Chris Gibes said: >You are absolutely correct. Co-location is by storage pool, not by >management class. So yes, you would need to carve your disk up into >multiple storage pools to selectively use co-location, Thanks for the confirmation >my guess is that it's >not viable to add more disk (or you're on one of those platforms where >disk is not "cheap"...) Expenditures are always political. Management is always more willing to spend huge gobs of money into a new disaster than drop a few more pennies into an existing one. And I'm more concerned about the management headaches than the cost, as you point out .. >the total amount of disk and the total amount >being backed up are going to be the same regardless of how many pools >you have, so carving one big pool up, shouldn't be that big of an issue, true, but >as long as you put some planning into the size of the disk pools. There's the catch. We can't plan more than 30 minutes into the future around here. It's easier to manage one big chunk of something than a bunch of little chunks. If we carve up our disk pools based on today's "plan", we'll have to re-configure them tomorrow. Our database has already exceeded the allocation that IBM told us was way bigger than we'd ever need, and we haven't even finished the installation yet. -- Matt Simpson -- OS/390 Support 219 McVey Hall -- (859) 257-2900 x300 University Of Kentucky, Lexington, KY 40506 <mailto:msimpson@;uky.edu> mainframe -- An obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's.
