Casper.Dik at sun.com wrote: >> Casper.Dik at Sun.COM wrote: >> >>> I'm not yet convinced that we need to get rid of the contents file >>> to get the performance we are after; the last prototype we did broke >>> badly for several reasons (excessive memory use, broken backward >>> compatibility). >> >> Watch next time during an install; initial packages are added quickly >> and as time goes on the system runs slower and slower. Towards the >> end of install we're write 15MB to disk to add a 100k package. > > That's not what I meant; I don't believe that it is necessary > to remove the existance of the contents file; not how it > gets there. >
The problem is that antique package postinstall scripts may use the contents file directly. > But it also seems that Peter Tribble statistics don't make this > an open and shut case. > There is often an implicit assumption that performance is somehow a linear function; this is not the case for significant changes. There are something like 1700 packages in Solaris 11 right now. Assuming all packages are the same size (or they're installed randomly), we end up writing 16/2 = 8MB 1700 times, or 13.6 GB of I/O. This is compared to the 2.7 or so GB that is Solaris fully installed. Thus removing the repeated writing of the contents file would reduce the amount of IO needed from about 16GB to 2.7 GB -> probably worthwhile. >> What I'd like to see happen here is that the first read of >> /var/sadm/install/contents causes a daemon to synchronously >> construct a cached, read-only version of the contents file >>from the actual contents information; the same file would >> be returned to others until pkgadd/pkgrm occurs mandating >> the creation of an new file. > > Why would a daemon need to do that? Just create the file and > exit. (pkg tools would then do something to make sure it gets > recreated on the next read). > Depends on how this file interposition tech. is going to work... > This, in my opinion, still points to a solution where the actual > database is cached in memory and updated and maintained by > that deamon; the daemon can then write the file at irregular > intervals (when it has been idle, when the system goes down) > and it would be started by any of the package commands). > As long as the daemon can prevent(block) other processes from reading the file while it's being constructed, that's fine. >> The Solaris packaging tools would not use this interface; >> it would be provided read-only for legacy apps and fingers. >> >> We don't support running previous versions of packaging tools >> on newer versions of Solaris; the Solaris 9 version of pkgadd > would not deal well w/ zones, for example. > > Well, we do, in some sense (live upgrade). > But note that Live Upgrade runs on the previous version of Solaris; it is only necessary that the packaging DB in a proper state when that finishes. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
