I've recently installed Hipster into a small VM with 1GB of RAM and wanted to update it from the February ISO state to current packages. What I found was that the virtual machine essentially froze in the process, and after a few increments of provided ram it succeeded when 2gb were dedicated (which is quite generous on an alas 4gb notebook).
During the 'pkg update' runs I saw that the process consumed over 900MB in virtual memory with about 600MB in RSS and lots of swapping occurred, at least during the Refresh-catalog and Solving stages. Something seems inefficient in this - the updates to download were less than this! Did anyone else see such behavior? Also, what should be the storage policy towards /var/pkg and in particular /var/pkg/publisher? It seems that the latter is a repo which stores copies of packages for the current BE and maybe also for new BE's that directly use this one as base for cloning (updates are fetched first, then a clone is made, and possibly the obsolete packages are removed from the cache). Overall this consumes quite a lot of space, which is not always easy to release without killing an older BE completely, so I womder if things can be optimized here somehow as well? In particular, I've tested with my split-rootfs procedure, that these both paths can be separated into datasets under each current rootfs, and it works for beadm clones. I guess it would make it easier to destroy old package caches when an rpool runs out of space, without necessarily destroying the relevant BE's. However, I am not yet certain what would happen when a booted or running BE would find itself with an empty /var/pkg/publishers - would it just re-fetch whatever it might need or would things crash badly? Should there be steps to reinitialize the cache after it is rudely deleted? Or conversely steps to gracefully purge it? Also, am i correct to assume that /var/pkg and its other subdirectories hold info about the actual installed packages and for the os/pkg management to remain sane - these should not be 'purged'? Thanks, //Jim -- Typos courtesy of K-9 Mail on my Samsung Android _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
