|
Andy, I think to remember that the system is worse than you described: mixing 8 GB and 17 GB drives results in half the percentage on the 17 GB compared to the 8 GB drives, because an arm is an arm and the controller does not know about the capacity "behind" this arm. So, if you you got a system with, for instance, 46 % used space on an 80 GB ASP consisting of 4x 8 GB (RAID5) and 4x 17 GB (RAID5) then the drive sets would look something like: 70 % space occupied on the 8 GB and 35 % used space on the 17 GB drives. This is only different when running ASP balancing or doing bulk unloads / reloads for large amounts of data. Generally speaking, I think one can much more easily overload a certain disk arm with drives of higher capacity than with a bunch of smaller drives. I would certainly be interested in the exact algorhythms behind these symptoms I watched on real systems out there. Regards from germany, Philipp Rusch Andy Nolen-Parkhouse schrieb: > John, > > My experience has been that the OS writes new data to the drive with the > least per cent utilization, until such time as all of the drives in that > ASP are equalized. Because of this, you need to be careful with empty > drives. If all new writes were random adds to DB files, then perhaps > there were not be much impact. But suppose you added a new 8.5 disk > drive to a system at 80 per cent disk utilization. Then you restore a 6 > GB library with full of database files. All of those database files > will be restored to that one drive and any application using that > database would beat the living daylights out of that single drive. The > same thing would occur if you did a copy of your largest database file; > it would all end up on that one drive. > > If you had a mixture of 8.5 GB and 17 GB drives, then the system would > spread the data until all drives were at an equal per cent storage > utilization. So you could expect your 17 GB drives to have twice as > much stuff as the 8.5 GB drives and thus twice the activity (assuming > the scatter loading is effective). This would be the reasoning for not > having an ASP with a wide discrepancy in disk sizes. > > The ASPBAL commands are pretty much required when adding new drives to > an ASP to avoid the activity imbalance. Purists (or traditionalists) > may still do a system reload under these circumstances. > > I've never seen an official explanation from IBM on their scatterloading > methodology. I hope someone can find one. > > Regards, > Andy Nolen-Parkhouse > > > -----Original Message----- > > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com] > > On Behalf Of John Ross > > Sent: Monday, June 03, 2002 10:56 AM > > To: midrange-l@midrange.com > > Subject: RE: New 270. > > > > I was told last week by a business partner, not to go over double the > size > > of your smallest dive in your system, so if you have a 4 do not go > over an > > 8. He tried to explain why but I really did not understand it. > Something > > about it would get more reads on the smaller drive. > > > > Would it matter how you let the system spread the data? If you just > put > > another drive in and do not force it to spread the data on the system, > it > > seams like the new data would be put on the new drive and might get > more > > reads then older data, at least for a while. If you are letting the > system > > spread the data (Not forcing it) does it only put writes on the new > drive > > or will it force data that it should only be reading to be moved. Does > the > > OS try to stay on the first drive(s)? (I think in my 38 days I heard > it > > did) IF so with 8's it might spread over 2 drives with 17's it could > all > > end up on the first drive. And it seams the OS would be used a lot. I > have > > used WRKDSKSTS for 15 min and the number 1 disk is 1st or second for > > percent busy, but only by 1%. > > > > Is there a link anywhere that explains how IBM spreads the Data? > > > > John Ross > > www.opensource400.org > > > > > > > > Subject: Re: New 270. > > > > > > > > Last year, I made the move from 6- 8 GB drives to 6-17 GB, and > > >performance > > > > suffered considerably. > > > > > > > > Al > > > > _______________________________________________ > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > > list > > To post a message email: MIDRANGE-L@midrange.com > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > > or email: MIDRANGE-L-request@midrange.com > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/midrange-l. > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.