Evan,
Doing more extensive unit testing for reusing manifests, the case in
which Target Instantiation rounds down to the nearest cylinder (thereby
shortening the preceding slice) was causing the algorithm to break
down. To accommodate this, modified the routine which seeks the best
fit to search for the best fit 1 cylinder smaller than originally requested.
Tested the reuse case using all possible slices at once, varying slice
sizes. Resulting VTOC is identical to the original.
Tested on x86 and SPARC.
Also, merged changes to ai_manifest.rng from 7794, and straightened
columns in logging functions.
Updated webrev.
Response to your question below:
On 04/ 8/10 07:05 PM, Evan Layton wrote:
On 4/8/10 10:28 AM, William Schumann wrote:
http://cr.opensolaris.org/~wmsch/bug-8661/
http://defect.opensolaris.org/bz/show_bug.cgi?id=8661
Added tag to AI manifest RNG schema ai_manifest.rng for slices:
slice_on_existing. Possible values:
"error" (default) - if a slice N already exists and is specified in a
slice create action, consider it a configuration error and terminate the
install to protect the slice.
"overwrite" - overwrite the existing slice N definition by first
deleting it in AI's internal representation of the VTOC, then effecting
the new slice creation.
In ai_manifest.rng it looks like we're putting in case sensitive
values for "error" and "overwrite". Shouldn't we be just putting
"error" and "overwrite" here and then adjusting the case elsewhere
when using the value?
377 <value>error</value>
378 <value>ERROR</value>
379 <value>Error</value>
380 <value>overwrite</value>
381 <value>OVERWRITE</value>
382 <value>Overwrite</value>
I just wanted to make sure we're not missing something with the
manifest changes above. What happens if the value is "OverWrite"?
The de facto policy in manifests has been not to insist on exact case
matching where case is irrelevant. However, there does not seem to be a
way of making RNG schemas case-insensitive, so each time there is a new
text element, there is a tradeoff decision: do we screen these keywords
during manifest validation (against the schema) on the AI server side,
or do we pass the text field and do the case-insensitive validation on
the AI client? This is one of the issues that a AI server-side semantic
validator would help with, if it existed.
So to answer your question, "OverWrite" would indeed fail. But if we
made the field a simple text field, then a random string of characters
would pass on the AI server side, but fail on the AI client during
installation.
The rest of the code looks ok to me.
Would you please take a look at differences in
disk_slices.c:find_free_region_best_fit() and consider whether the
change in logic will have unexpected ramifications?
Thank you,
William
-evan
Added new parameter to om_create_slice() to indicate the option.
Added default value to ai_manifest.defval.xml as array placeholder (the
usual workaround).
Implemented as an enum to facilitate addition of other options in the
future.
Cleaned up some old lint in auto_parse.c.
Testing: created error conditions, checked behavior of overwriting
slice, multiple slices, tested proper manifest validation, tested
defaulting.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
