In der Reihenfolge der Effektivität und wie einfach die Lösung ist:
- Mehr Speicherplatz kaufen: Das Platzieren von $TMPDIR auf einer eigenen SSD hilft sehr und beseitigt die Notwendigkeit des Mikromanagements.
- Löschen Sie $TMPDIR (build/tmp): Alte Images, alte Pakete und Arbeitsverzeichnisse/Sysroots für MASCHINEN, für die Sie derzeit nicht bauen, sammeln sich an und können ziemlich viel Platz beanspruchen. Normalerweise können Sie ab und zu einfach das gesamte $TMPDIR löschen:Solange Sie sstate-cache verwenden, sollte der nächste Build immer noch ziemlich schnell sein.
- Löschen Sie $SSTATE_DIR (build/sstate-cache): Wenn Sie viele Builds durchführen, sammelt sich sstate mit der Zeit an. Das Löschen des Verzeichnisses ist sicher, aber der nächste Build wird lange dauern, da alles neu erstellt wird.
- $DL_DIR löschen (Build/Downloads): Wenn Sie ein Build-Verzeichnis längere Zeit verwenden (während Sie Updates vom Master abrufen oder zu einem neueren Zweig wechseln), nehmen die veralteten Downloads weiterhin Speicherplatz in Anspruch. Denken Sie daran, dass das Löschen des Verzeichnisses bedeutet, dass alles neu heruntergeladen werden muss. Sich nur die größten Dateien anzusehen und die alten Versionen zu löschen, kann hier ein nützlicher Kompromiss sein.
Es gibt einige offizielle Möglichkeiten, anstatt zu löschen.
Durch absichtliches Löschen könnten Sie unnötige Builds und Downloads erzwingen. Einige Elemente des Builds können nicht von Bitbake gesteuert werden, und Sie können sich in einer Situation befinden, in der Sie diese Elemente nicht auf einfache Weise wiederherstellen können.
Mit diesen Empfehlungen können Sie die nicht geschriebene Yocto-Regel von 50 GB pro Build übertreffen:
Überprüfen Sie Ihre IMAGE_FSTYPES Variable. Meiner Erfahrung nach ist es sicher, alle Bilder dieser Dateien zu löschen, die keine Symlinks oder Symlink-Ziele sind. Vermeiden Sie den zuletzt generierten, um zu vermeiden, dass der letzte Build-Link und alle damit verbundenen Bootloader und Konfigurationsdateien beschädigt werden, da sie selten neu generiert werden können.
Wenn Sie mehr als einen Build mit demselben Ebenensatz behalten, können Sie einen gemeinsamen Download-Ordner für Builds verwenden.
DL_DIR ?="common_dir_across_all_builds/downloads/"
Und danach:
So halten Sie Ihr /deploy sauber:
RM_OLD_IMAGE: Gewinnt Speicherplatz zurück, indem zuvor erstellte Versionen desselben Images aus dem Images-Verzeichnis entfernt werden, auf das die DEPLOY_DIR-Variable verweist. Setzen Sie diese Variable in Ihrer local.conf-Datei auf "1", um diese Images zu entfernen:
RM_OLD_IMAGE = "1"
IMAGE_FSTYPES Entfernen Sie die Bildtypen, die Sie nicht verwenden möchten. Sie können jederzeit einen bestimmten Typ aktivieren, wenn Sie ihn benötigen:
IMAGE_FSTYPES_remove = "tar.bz2"
IMAGE_FSTYPES_remove = "rpi-sdimg"
IMAGE_FSTYPES_remove = "ext3"
Benötigen Sie für /tmp/work nicht alle Arbeitsdateien aller Rezepte. Sie können angeben, welche Sie an Ihrer Entwicklung interessiert.
RM_WORK_EXCLUDE :Wenn rm_work aktiviert ist, gibt diese Variable eine Liste von Rezepten an, deren Arbeitsverzeichnisse nicht entfernt werden sollen. Weitere Einzelheiten finden Sie im Abschnitt "rm_work.bbclass".
INHERIT += "rm_work"
RM_WORK_EXCLUDE += "home-assistant widde"