Dave Miner wrote: > I thought Sarah's answers were pretty good in most respects, but I'm > not so keen on this one: > >>> Database >>> -------- >>> If there is any way at all possible to use SQL-Light, Berkeley DB, >>> or similar light database client to offer an option over the >>> "contents" file as we know it today, that would be swell. I'm ok >>> with the contents file and amazed it doesn't get more corrupt on >>> more systems, than it has. This causes us a lot of time during >>> package installation I would guess, but not certain. >>> >>> >> the /var/sadm/install/contents file is one of the reasons it takes >> time to do installations. And, it is a single point of failure for >> sure. As to the solution, there have been a few bandied about. One I >> thought had some promise was doors as files: >> http://approach.sfbay/wiki/index.php/Doors-As-Files >> > > We tried replacing this once, and it was a disaster - one of the few > projects I can recall being backed out and completely abandoned after > integration; it wasn't for lack of effort on the team's part, it just > didn't end up providing measurable benefit and carried a great deal of > cost. People bring up this idea occasionally, but I always feel it's > a solution looking for a problem. Usually the grounds are > performance, but I'd suggest reviewing the thread Peter started at: > > http://www.opensolaris.org/jive/thread.jspa?messageID=31892粔 > > before proceeding with that argument. This is a good analysis of the data regarding what takes time during install. Thanks for forwarding it. > > And I can't say I'm a fan of "Doors as files"; if your premise is > points of failure, I don't see throwing a whole bunch more mechanism > in the way as being an improvement in that respect. We can do all > sorts of things to make the contents file safer from corruption if > that's really the issue (my perception is that it's rarely a problem, > but perhaps I'm just not seeing the data). Right now it wouldn't even > make my personal top 100 things to do. I didn't assume the central issue was corruption. I assumed the central issue was the need to write to the contents file for every package add/remove and that this was a time consuming process, basically a performance issue. Peter's analysis does indicate that this does take ~1/3 of the install time.
Doors as files was just a data point, not a suggestion of the right way to go. I have seen many other suggestions, PSARC cases, none have which resolved anything. So, I agree with you that this isn't high on our list, nor do we likely understand the whole issue. This was just a possible thing to look at. > > So, please, let's define and characterize the extent of the "problem" > with the contents file before charging at it once again. That's fair. thanks, sarah ****
