Contents
Freeing disk space on servers
Build nodes
These collect chroots under /home/iurt/chroot_tmp/iurt/. The longest possible build as of this writing will take 2 days, so running find /home/iurt/chroot_tmp/iurt/ -xdev -maxdepth 1 -type d -mtime +7 will show some candidate directories to delete. Make sure to unmount anything mounted in those chroots first, like procfs (check mount). While you're cleaning up, unmount any stale nfs mounts for these chroots from /run/netns/chroot_cauldron.*.
binrepo
This holds all the source archives for packages alongside the spec files (which are in svn). Deleting files from here means that it becomes impossible to submit a package to the build system that requires that binary archive to build. We need to be able to rebuild from source for currently-supported releases to apply security patches. There are also legal requirements to retain source code for a period under some Open Source licenses (e.g. GPL). Don't just delete files wantonly.
Source RPMs also contain the binrepo files, so if a file is removed from binrepo it can be recovered from the associated .src.rpm (assuming we have it around in a long-term archive). So, if a file was in a src.rpm for an obsolete mga release, if we can recover it if needed, and if it is no longer used in cauldron or any current mga release, then it should be fine to remove it.
distrib
This holds all RPMs and metadata for all supported releases. When this fills, nobody can build any more packages. One strategy to free space is to hard link identical RPMs between bootstrap and mirror for cauldron. Another is to remove obsolete and unsupported releases, although you must first ensure the files are available elsewhere in case we need to fulfill any obligations under the GPL (and other licenses) to provide source code (this responsibility may not actually apply, but you need to be sure about that before deleting).
log
If the log partition (/var/log/) is filling up, there are a few things that can be done to make space. Running journalctl --vacuum-size=500M (with an appropriate size) will make some room immediately by deleting enough older logs so the remainder fit in the given space. Permanently reducing journal log sizes can be done by changing /etc/systemd/journald.conf for the host in puppet.
If other logs which are rotated by logrotate are getting too large, the logrorate settings may need to be tweaked. Logs are normally rotated monthly, so changing that to weekly will compress the log files much more often leaving more free space. This can be done by changing the logrotate settings for a service in puppet, possibly using a <% if @hostname == 'HOST' %> conditional. When changing the log rotation period, make sure to also change the number of logs to keep around (the rotate value); e.g. if changing from monthly to weekly, the maximum number will need to be increased by a factor of 4 to keep around the same log history available.
Expanding partitions
Many partitions on Mageia servers are provisioned using lvm. This means that it's possible to add space to a partition relatively easily. Run vgdisplay and look if there is any space available in the Free PE lines for the given volume group. If so, it's tricky, dangerous but possible to add this space to an existing partition, then resize the filesystem to fit, without even unmounting the filesystem.
