On 03/ 1/10 03:20 AM, casper....@sun.com wrote:
...
For example, on my system, when I did an image-update from build 110 to
build 111, with all of the data to be installed downloaded already, it
only took about five minutes to upgrade 666 packages and move around 480
megabytes worth of data. That's not too shabby if you ask me.
Compare upgrading from build 128 to later :-)
Sorry, I meant from build 118; the continuous rewriting of the contents
file was a bug which was easily fixed. I don't think you should benchmark
against a completely broken system; to use that then your bar would by
very low.
So I checked back into this. Significant performance regressions and
improvements both occurred during builds 118-132 for pkg(5). So
depending on what build you were upgrading from and to, you could have
seen wildly varying performance during image-update.
On my laptop (with a 4200 RPM hard drive I might add, but 4GB memory),
it took around 7 minutes on average to upgrade from build 131 to build
133, using the gate version of pkg (which will be delivered in 134),
which was comprised of:
* updates to 1,528 packages (comprised of 13,504 files)
* 423.4MB of data retrieved (not already cached)
* 13,414 removals; 48,509 installs; 19,245 updates
I'd say that's pretty good, and the good news is that time should go
down even further in the future...
What was interesting is that "zfs" improved the old contents file issue on
systems with more than 1GB of memory; with "ufs" each update of the
contents file was completely written to disk; this one done at least twice
for each package. With zfs much of the contents file was never written to
disk.
...
Yep, the old SVR4 pkg system is much better than it used to be.
However, it also only has to manage a few thousand package versions (at
most). pkg(5) has to manage information for over 68,000 unique package
versions currently for builds all the way from 86-133.
I greatly appreciate the time you've spent to provide feedback and
insight into your own forays into this area.
Cheers,
--
Shawn Walker
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
