On Mon, Feb 2, 2015 at 9:42 AM, Gary Thomas <g...@mlbassoc.com> wrote:
> * The sstate-cache for a given build/target seems to grow > without bounds. I have one build which I've been reusing > since last November has grown to 62GB. A very similar > build which hasn't see quite so many 'bakes' is only 27GB. > > Is there some maintenance to be done on the sstate-cache? > I'm thinking I want to set up a shared cache which might > last for a long time and I would like to only keep the bits > that are really needed. > In the past i've either used sstate-cache-management.sh or ensured that SSTATE_DIR is on a mount with atime enabled and just periodically wiped anything that hasn't been accessed in over a week. * The second operational question I have is if I have a shared > sstate cache and I make some sort of build, what is the best > way (if any) to share any newly created objects so that my > other builds can make use of them? > I doubt there's a "best" on that. Personally I either use a shared filesystem path (e.g. nfs) or hook up rsync. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
