On 6/27/06, Jeff Victor <[EMAIL PROTECTED]> wrote:
1) General comment: I agree that this will provide needed clarity to the seemingly unorganized RM features that we have scattered through Solaris during the last decade. The automation of certain activities (e.g. starting rcapd in the GZ when needed) will also be extremely beneficial.
2) Terminology: Although your use of the phrase "hard partition" should be clear to most people, through experience with other partitioning technologies, the use of "soft partition" is less clear. To many people, a "soft" limit is one that can be exceeded occasionally or in certain situations, or is merely an advisory limit. It also conflicts with SVM "soft partitions." I suggest the phrases "dedicated partition" (or "private partition") and "shared partition" instead to clarify the intent. Choosing "dedicated partition" might then require re-naming "dedicated-cpu" to "guaranteed-cpu" or "private-cpu" and re-naming "dedicated-memory" to "guaranteed-memory" or "private memory". Or we could leave "hard partition" alone and simply change "soft partition" to "shared partition."
I think that "soft partition" is more clear. "Shared partition" suggest to me that you are sharing a single hard or soft partition for multiple workloads.
3) Lwps context: Why is the lwps alias defined in the context of dedicated-cpu? Lwps seem to be unrelated to hard partitions. Further, ncpus represents a subset of a finite resource. Lwps are not finite. The two should be separate.
Something seemed odd with that to me too. I didn't see it as terribly harmful there, but it is an excellent point. This is analagous to maxuprc typically set in /etc/system. What are the chances that each zone in the future gets file descriptor limits or other similar limits that should be in the same section as the lwp limit?
4) Aliases: The notion of aliases also creates redundant output which could be confusing. I like the simplification of aliases as described, but I wish I had a good solution that wouldn't break existing tools that parse "zonecfg info" output - if such tools exist.
Because key features are missing from zones, I have been writing scripts that sometimes parse the output of "zonecfg info". Changing this format stands a good chance of breaking my scripts. It sounds like if I set pool and rctl resources, they would still be displayed as rctl and not translated to the syntax associated with temporary pools. Is this correct? Mike -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zones-discuss mailing list email@example.com