Quoth Alan Maguire on Tue, Jun 10, 2008 at 04:19:31PM +0100: > I've been looking into a candidate solution for supporting > the ordering of property values in the SMF repository.
Wow, Alan, this is great work! I hope hacking on svc.configd didn't make you pull too much hair out. > The subject of the ordering of property values has come > up here a few times before, for example see: > > http://www.opensolaris.org/jive/thread.jspa?messageID=53690톺 So what is your take on Stephen's network repository issue? I wonder if we could add a piece of metadata to properties which specify whether they're ordered or unordered. By default they'd be ordered, but if an application doesn't care then it can make them unordered, which would free svc.configd to avoid emulating order in an unordered backend. Or maybe the ordering should be a flag on the retrieval interface. Or maybe the current retrieval interfaces should be designated "ordered", and we can add separate unordered retrieval interfaces. If we wanted to do this, we could probably put it off actual unordered properties until we have a network backend, and make any interface changes as opportunities arise. > To support ordering at the repository level, I suggest > adding an additional column to the value_tbl, named > value_order. When we add property values, we would > need to also specify ordering (0, 1, 2, ..) for this column. > On retrieval then, we can modify the backend SELECT > statement to ORDER BY the value_order column and > thus ordering is preserved. Sounds good. > A major concern with such a change of course is > handling upgrade to a new repository format, while > also supporting downgrade from the new format to the > previous format. To ensure svc.configd can deal > with the repository format, the repository carries a > schema version number which must match the version > encoded in svc.configd in order for the repository > to be usable. My suggestion is that we do not bump > this version number for this change. A downgraded > svc.configd can actually handle a repository with the > extra value_order column perfectly (it merely ignores it). > It might make sense introduce a minor version number into > the schema_version table, to reflect that the schema > has changed, but not in an incompatible manner. Is supporting downgrade a hard requirement? > This leaves the issue of upgrading to the new > repository format. Ideally, we would like to > add the new column as soon as the repository > is writable on upgrade, but we have to deal > with a few complications: > > - during boot, we need to read property values prior to the > point when we can do the repository upgrade (i.e. prior to > the repository being writable) > - the version of sqlite used does not support the ADD COLUMN > command, so adding a new column to the value_tbl > is not straightforward. > > To address the first issue, we need to keep track of > whether upgrade has been carried out for a particular > backend. This is important, because during first boot > post-upgrade, we will need to read values before > we can write to (and upgrade) the repository. This > means we need to modify the SELECT statement > that retrieves values based on whether the upgrade > has been done (since prior to upgrade it cannot use > the ORDER BY value_order clause in the SELECT > statement that retrieves values). True. We should be able to assume that the nonpersistent repository is in the new format, though, shouldn't we? Unless I suppose we want to support changing the svc.configd binary without rebooting. Did you happen to determine when ADD COLUMN was added? If was before 3.0, upgrading might be an option. David > I've posted a webrev which contains what I have so > far: > > http://cr.opensolaris.org/~amaguire/smf_values/ > > I've confirmed this approach works, and supports > upgrade/downgrade, but I think it needs some additional > investigation to be determined sufficiently robust (I still see > one complaint about the lack of a value_order column during > first boot post-bfu). I'm assuming we'd also need to assess the > impact on performance (if any) that adding an additional column > to the value table would have, but I thought it'd be useful to have > a rough candidate solution to start discussing how/if the ordering > issue can be resolved.
