On Tue, Dec 13, 2005 at 11:19:23AM +0100, Carsten Otte wrote: > I second your thoughts regarding block vs track caching, > but I doubt that a scenario exists where MDC for non-shared > mdisks outperforms reasonable distribution of the available > storage to the linux images. Would you care to show such > measurement?
It's likely that there is not one. :) The key point you've stated (and what I believe you've missed in Barton's message) is the "reasonable distribution of the available storage". Basically, what is reasonable for one set of guests may not be the most effective for another set. Barton wrote: > > Another part of this consideration, with xx servers, they > > are not all likely to be active at one time. So we need a > > way to move the cache storage from the idle servers to the > > active ones. If linux owns the cache, this is not possible. > > We control the linux server cache size > > by minimizing the linux servers, so that there is less room for > > cache. and further: > > And there is no reason to believe that allowing disks > > that are only used by one server to be mdc cached is a > > bad idea. How else can you give a server a couple hundred > > MB of cache dynamically when it needs it? For "active" and "inactive" here we are talking about DASD activity, not whether or not the guest is logged on to VM. In the case where you are tuning your storage sizes to cache in Linux, to give acceptable performance you have to size for peak load, which results in *all* of your guests being allocated storage to use as cache. Let's say 10 guests with 20MB each as cache. You've made a decision to burn 200MB of storage across the environment as cache -- but it's in small bites that *none* of the guests can make total use of in a burst of activity. Allocating cache centrally (a la MDC) makes that total amount of cache available to *any* of the guests that wish to use it in any amount. A system that needs a stack of cache for a time can borrow it from other guests that aren't needing it during that interval. To me it's another example of trading-off between getting absolute maximum performance and the greatest flexibility in the environment. Cheers, Vic Cross ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
