|
Description
|
At present, the SMF repository does not store ordering information with property values in the SMF backend, which is an SQLite database. Values are updated without adding ordering information, and retrieval is done via a SELECT operation that specifies no particular order. Adding a value_order column to the table that contains each value (value_tbl) would allow values to specify an additional order (0, 1, 2, ...) that could be used in retrieval via an "ORDER BY value_order" clause in the SELECT statement. Addditionally, libscf's scf_entry_add_value() function would need to be fixed to support addition of values at the tail of the value list, rather than the head (which reverses the order of values to be committed). This can be done in a backwards-compatible manner, meaning that svc.configd in previous Nevada builds could use the upgraded repository, since the additional value_order column would simply be ignored (in defining it, it should default to 0).
The only complication is first boot post-upgrade to a build supporting value ordering Early in boot, the repository is readonly, and thus cannot yet be upgraded, yet we
need to retrieve values. The SELECT operation that does this then would have to
determine if the repository has been upgraded, and if not, use the old, value-order-neutral SELECT operation. Later, once the repository is writable, it will
be upgraded, and the value-order-specific SELECT operation can be utilized.
Just to add, further testing has revealed a few more changes are needed. In upgrade
handling, we also need to catch the case where the persistent repository is
immediately writable on boot, and effect an upgrade then - this case occurs with
nonglobal zones.
Also, in order for multivalued properties contained in manifests to import correctly,
some svccfg changes are needed. More specifically, for import we need to change the
uu_list that stores such values from a list sorted via strcmp() lexical comparison to a simple ordered list where additional values are appended to the end of the list.
Suggested fix has been updated accordingly (those these comments really belong
in the evaluation section, it's not publicly available).
updated suggested fix again, for a 1-line change adding a VACUUM SQLite command - this reduces the size of the repository database post-upgrade (as the moving around
of tables required during update increases it).
suggested fix updated to remove "eventually we'll support upgrade" comment.
|