How should the sstate-cache directory be deleted in Yocto?

Question

The size of my sstate-cache directory of my YoctoProject "fido" environment is more than 3GB. How can I delete the sstate-cache directory in yocto/build-dir?

Is it safe to use rm -rf or is there any other method?

Saprophyte

Answer 1

According to the Yocto Reference Manual it is safe to remove the complete build/tmp directory including the sstate-cache directory:

As a last resort, to clean up a build and start it from scratch (other than the downloads), you can remove everything in the tmp directory or get rid of the directory completely. If you do, you should also completely remove the build/sstate-cache directory. (see [1] and [2])

Furthermore you can remove the sstate-cache with bitbake for a specific recipe by calling do_cleansstate like shown below (see do_cleansstate).

$ bitbake -c cleansstate recipe

Please be aware that the Shared State Cache needs a lot of memory and it will be growing again to the size it needs to build your images.

More detailed information on the Shared State Cache is available in following sections of the Yocto Reference Manual: Shared State Cache and sstate-cache.

Khadijahkhai

Thanks @g0hl1n, you mean all compiled recipe data is present in the sstate-cache dir right. if i remove dir all recipe data i will lost right? – Saprophyte

Hi, no not all compiled data is in sstate-cache, some is also in the workdir. And you will lose no recipes by removing sstate-cache. But please read the reference manual (linked in the answer) for more details on that issue. – Khadijahkhai

Don't know how it is in your case, but in mine, the build/tmp does not include the sstate-cache. But as the note says, if you remove the sstate-cache folder inside your build folder, you should remove the tmp folder as well. – Disobey

Answer 2

The correct task for this is:

$ bitbake -c cleansstate <recipe-name>

See: Yocto Reference Manual

There are more tasks for cleaning, which remove sstate cache and even more (e.g. do_cleanall).

Habitude

New link of yocto reference docs.yoctoproject.org/ref-manual/… – Karlene

Answer 3

It is safe to delete the sstate-cache directory, however the proper way to reduce its size is by using the script in poky/scripts/sstate-cache-management.py which will remove older entries. See https://git.yoctoproject.org/poky/tree/scripts/sstate-cache-management.py (the script was sstate-cache-management.sh in older versions)

Forbes

Answer 4

You can delete sstate-cache from build and most common reason for it is, since it keeps growing as more and more cached data is added for every build. There is an easy way of cleaning it, as follows:

./scripts/sstate-cache-management.sh --remove-duplicated -d --cache-dir=<path to sstate-cached>

This removes the duplicated and old data from the cache.

NOTE: When we need to rebuild from scratch, we either remove the build/ tmp so that we can use sstate-cache to speed up the build or we remove both build/tmp and sstate-cache so that no cache is reused during the build.

Electroencephalograph

Answer 5

I have bold the part that has the command to reduce size of the sstate cache; This is an alternative way to clean up the cache.

https://old.yoctoproject.org/sites/default/files/yocto_devday_advanced_class_sandiego.pdf slide 37

Sstate: recommendations

• In complex systems it is recommended to separate sstate directories, for example native and non-native sstate directories, and also different BSPs and arches.

• Reusing a single directory will grow very large very quickly. Use atime to delete old files. Note: this requires the filesystem mounted with atime/relatime which we normally recommend to disable for build performance.

find ${sstate_dir} -name 'sstate*' -atime +3 -delete

• Rebuild sstate to new directory periodically and delete old sstate dir to maintain bounded size. There may be packages or package versions that are no longer used and just take up space.

• Although it is possible to use other protocols for the sstate such as HTTP and FTP, you should avoid these. Using HTTP limits the sstate to read-only and FTP provides poor performance.

• Additionally, a missing sstate file on http/ftp server cause wget to hang for a long time due to the retries and timeout

Hermes

I'm not sure what the 'fi*' is, but without it's working fine. – Wellrounded