On Tue, Jun 09, 2009 at 11:13:51AM -0400, Dave Miner wrote: > Darren Reed wrote: > >This sounds nice but what will the implementation > >of this be? > > > >If we move towards a design where there is an FMRI > >that looks after each file, are we going to end up > >with countless more FMRIs that are just for massaging > >these files? > > > > Countless? Doubtful. I'd put the upper bound at a few dozen. There > really aren't that many of these types of files.
Yes, but the model seems likely to lead to N*M FMRIs, where N is the number of editable files/directories/whatever, and M is the number of unrelated pkgs delivering updates to them. To get this count down to just N we'd need to have well-defined FMRIs for these purposes. > >Is the use of Actuators synchronous or asynchronous? > >And if there are multiple Actuators specified? This has been answered: it's synchronous. > >My fear is that we are creating too many FMRIs and that > >in doing so, we're creating problems for ourselves in > >the future. Current FMRI count is closing in on 300 in > >Nevada. Nearly 3 times the number from S10FCS. One might > >therefore reasonably conclude that Nevada therefore takes > >3 times as long to boot as S10FCS. (I don't know if that > >is accurate, it's speculation based on numbers.) It's > >not any one person/project that's been responsible for > >this, it looks like like death by 1000 cuts. SMF manifest import is now very fast. (It's done with the repository temporarily moved to tmpfs, then the repository is moved back to persistent storage. That makes the fsync() burden of every little transaction, which comes from SQLite2, go away.) > Fear not. To the contrary, the number of services on the system > indicates success on a number of fronts: +1 > The number of services that might be installed is an irrelevance, > frankly, and not something to be optimized based on data-less notions of > system performance, or misguided notions of system cleanliness. I'm not so sure. There are some minor problems with a very large number of SMF services: - potentially more for the customer to understand when something goes wrong - if there's no naming convention for related services then the result may/will be aesthetically not pleasing A bigger problem, I think, is this: how would one know that _all_ self-assembly is complete? One possibility: when all enabled services are online. (Whatever the answer, an answer is needed.) > If boot time is a problem with the number of services we have (I'm not > aware of evidence), the problem to be solved is how to make SMF scale > better, not roll back any of the above advances. +1 Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
