Par ordre d'efficacité et de facilité de réparation :
- Achetez plus d'espace disque : Mettre $TMPDIR sur un SSD lui-même aide beaucoup et supprime le besoin de microgestion.
- Supprimer $TMPDIR (build/tmp) : les anciennes images, les anciens packages et les répertoires de travail/sysroots pour les MACHINES que vous ne construisez pas actuellement s'accumulent et peuvent prendre beaucoup d'espace. Vous pouvez normalement supprimer l'intégralité de $TMPDIR de temps en temps :tant que vous utilisez sstate-cache, la prochaine construction devrait être assez rapide.
- Supprimer $SSTATE_DIR (build/sstate-cache) : Si vous faites beaucoup de constructions, l'état lui-même s'accumule au fil du temps. La suppression du répertoire est sûre mais la prochaine construction prendra beaucoup de temps car tout sera reconstruit.
- Supprimer $DL_DIR (version/téléchargements) : Si vous utilisez un répertoire de construction pendant une longue période (tout en extrayant les mises à jour du maître ou en passant à une branche plus récente), les téléchargements obsolètes continuent de prendre de l'espace disque. Gardez à l'esprit que la suppression du répertoire signifiera tout télécharger à nouveau. Examiner uniquement les fichiers les plus volumineux et supprimer les anciennes versions peut être un compromis utile ici.
Il existe des moyens officiels au lieu de supprimer.
En supprimant délibérément, vous pourriez forcer des builds et des téléchargements inutiles. Certains éléments de la construction peuvent ne pas être contrôlés par bitbake, et vous pouvez vous retrouver dans une situation où vous ne pouvez pas reconstruire ces éléments de manière simple.
Avec ces recommandations, vous pouvez battre la règle non écrite de 50 Go par build yocto :
Vérifiez vos IMAGE_FSTYPES variable. Mon expérience indique qu'il est prudent de supprimer toutes les images de ces fichiers qui ne sont pas des liens symboliques ou des cibles de liens symboliques. Évitez le dernier généré pour éviter de casser le dernier lien de construction, et tout ce qui concerne les chargeurs de démarrage et les fichiers de configuration, car ils pourraient être rarement régénérés.
Si vous conservez plusieurs versions avec le même ensemble de couches, vous pouvez utiliser un dossier de téléchargement commun pour les versions.
DL_DIR ?="common_dir_across_all_builds/downloads/"
Et après :
Pour garder votre /deploy propre :
RM_OLD_IMAGE : Récupère de l'espace disque en supprimant les versions précédemment construites de la même image du répertoire d'images pointé par la variable DEPLOY_DIR. Définissez cette variable sur "1" dans votre fichier local.conf pour supprimer ces images :
RM_OLD_IMAGE = "1"IMAGE_FSTYPES Supprimez les types d'images que vous ne prévoyez pas d'utiliser, vous pouvez toujours en activer un en particulier lorsque vous en avez besoin :
IMAGE_FSTYPES_remove = "tar.bz2"
IMAGE_FSTYPES_remove = "rpi-sdimg"
IMAGE_FSTYPES_remove = "ext3"
Pour /tmp/work, n'avez pas besoin de tous les fichiers de travail de toutes les recettes. Vous pouvez spécifier ceux qui vous intéressent dans votre développement.
RM_WORK_EXCLUDE :Avec rm_work activé, cette variable spécifie une liste de recettes dont les répertoires de travail ne doivent pas être supprimés. Voir la section "rm_work.bbclass" pour plus de détails.
INHERIT += "rm_work"
RM_WORK_EXCLUDE += "home-assistant widde"