From: Mike Crowe <mac@mcrowe.com>
To: openembedded-core@lists.openembedded.org
Subject: Over-pruning the sstate cache
Date: Tue, 29 Mar 2016 13:56:26 +0100 [thread overview]
Message-ID: <20160329125626.GA11712@mcrowe.com> (raw)
80b3974081c4a8c604e23982a6db8fb32c616058 implies that at least some people
are pruning the sstate cache based on file access time.
We run incremental and nightly Jenkins jobs that build images for various
targets and branches in order to keep the sstate-cache populated. Files are
pruned once they haven't been accessed for a few days. This has worked
reasonably well for a few years (and the script can be simplified now since
the above commit.)
Recently we've found that files that are still required are being pruned.
This appears to be due to a combination of improvements to oe-core to avoid
unnecessary tasks and improvements to our own recipes. These have resulted
in it being possible to build an image without requiring the
populate_sysroot.tgz files if nothing has changed that needs building.
Is there a recommended way to ensure that all the sstate cache files are
touched, even those that are not actually required to build the image
currently due to task optimisation?
The only solution I can come up with is to invent a recursive
"all_populate_sysroot" recrdeptask that depends on the individual
populate_sysroot tasks and run that task for each image.
Does anyone have any better ideas?
Mike.
next reply other threads:[~2016-03-29 13:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 12:56 Mike Crowe [this message]
2016-03-29 14:11 ` Over-pruning the sstate cache Richard Purdie
2016-03-30 13:05 ` Mike Crowe
2016-04-12 18:51 ` Mike Crowe
2016-04-12 20:50 ` Richard Purdie
2016-04-13 13:47 ` Otavio Salvador
2016-04-13 14:01 ` Mike Crowe
2016-04-13 14:11 ` Otavio Salvador
2016-04-13 15:27 ` Mike Crowe
2016-04-13 21:33 ` Paul Eggleton
2016-04-13 21:59 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160329125626.GA11712@mcrowe.com \
--to=mac@mcrowe.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox